Is this one of the GRBL bugs?

[cncmachineguy]

Right now I can click on "grab a part" and commands are sent to my motion controller. In fact it sends M800.1 to say turn on vac for nozzle 1.

When I hit the "Discard" button an M9 is sent which right now turns off the vac.

So heres the rub, doing it like that seems to take an inordinate amount of time for the led to turn on (led represents vac).

Also I will get a timeout error on the M800.1 and the M9.

BUT, if I send M800.1 or M9 from the console in driver setup, the response is instant - almost as soon as I release the mouse button.

So I was thinking this may be becasue it takes too long for the controller to "move" to the pickup/discard spot (and since I have no machine connected as yet I don't see movement) the Mxx is not "ok"ed. AND --heres the buggy part?--- no command is sent to say the move is complete, ok is sent when command is recieved. So I am assuming oPNP thinks the move is made and sends the next step (M800.1) but since move is not finished that does not get executed fast enough. I tried to set the feeder to it is only 1 mm from 0 so the move would get made fast. this did not seem to help.

Sorry if I am rambling

[Marek T.]

Have you configured properly the Regex command in driver to be in agree with responded from GRBL?

Leave the timings problem (...assuming oPNP thinks the move is made...). Create just some actuator and try send some command from it. It will be free of any other dependencies (other finished/notFinished operations).

[bert shivaan]

I will give this a try tomorrow first thing, do you mean using this dialog box? I suppose I just set the boolean values to be the same codes? (M800.1 and M9)

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+unsubscribe@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/feece46c-485e-4ddc-b827-5d0a5a3f460b%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Marek T.]

M8{True:10}{False:11}.{Index:%s}

It will send M810.% when you set actuator ON (true) and M811.% if you set off (false).

% - depend on the actuator index. You can create more actuators with the same name and indexes in agree with nozzles numbers.

If you want send concretely M800.1 and M9 set:

M{True:800.1}{False:9}

(I havent tested that settings but should be ok)

W dniu piątek, 14 września 2018 02:53:12 UTC+2 użytkownik cncmachineguy napisał:

I will give this a try tomorrow first thing, do you mean using this dialog box? I suppose I just set the boolean values to be the same codes? (M800.1 and M9)

On Thu, Sep 13, 2018 at 8:32 PM, Marek T. <marek.tw...@gmail.com> wrote:

Have you configured properly the Regex command in driver to be in agree with responded from GRBL?

Leave the timings problem (...assuming oPNP thinks the move is made...). Create just some actuator and try send some command from it. It will be free of any other dependencies (other finished/notFinished operations).

W dniu piątek, 14 września 2018 02:00:21 UTC+2 użytkownik cncmachineguy napisał:

Right now I can click on "grab a part" and commands are sent to my motion controller. In fact it sends M800.1 to say turn on vac for nozzle 1.

When I hit the "Discard" button an M9 is sent which right now turns off the vac.

So heres the rub, doing it like that seems to take an inordinate amount of time for the led to turn on (led represents vac).

Also I will get a timeout error on the M800.1 and the M9.

BUT, if I send M800.1 or M9 from the console in driver setup, the response is instant - almost as soon as I release the mouse button.

So I was thinking this may be becasue it takes too long for the controller to "move" to the pickup/discard spot (and since I have no machine connected as yet I don't see movement) the Mxx is not "ok"ed. AND --heres the buggy part?--- no command is sent to say the move is complete, ok is sent when command is recieved. So I am assuming oPNP thinks the move is made and sends the next step (M800.1) but since move is not finished that does not get executed fast enough. I tried to set the feeder to it is only 1 mm from 0 so the move would get made fast. this did not seem to help.

Sorry if I am rambling

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.

To post to this group, send email to ope...@googlegroups.com.

[bert shivaan]

That works perfectly Marek

M{True:800.1}{False:9} 

every time I press on or off, LED responds instantly.

I think this is a timing thing, I have GRBL sending "md" when a move is done (i think), now to get oPNP to wait for the move to be done instead of throwing "timeout waiting for move to complete". I am pretty sure I read something about this somewhere, so I am going to spend some time chasing that down.

Thank you for the continued support, there is lots to learn about the setup for a newbie. But this is what makes it SO powerful!!

To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+unsubscribe@googlegroups.com.

To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/79708567-c246-4e1d-803a-516526fa4f3d%40googlegroups.com.

[bert shivaan]

OK, something new learned. I can watch tx rx leds on the mega board. when I jog I see the both flash (I assume this is sending the command then mega responding with ok. if the jog step is big like 20mm, there is a few seconds then tx flashes. I assume this is mega telling oPNP move complete. (sending md) If I increase the jog step to 100, oPNP will time out before the tx flashes, but it will flash.

Testing my confirm move regex, if I set it tto mdd in oPNP, the Tx light flashes but oPNP still gives me a timeout even on small moves. set it back to md and small moves are all good. So maybe I will play with the command timeout setting in the case my machine is too slow?

[Marek T.]

I don't know GRBL.

In Smoothieboard there is M400 code which you can send to Smoothie after sending new position XYZ. And Smoothie will answer for M400 when finished the move only (concretely when the command before is realised).

M400 << Wait for the queue to be empty before answering “OK”>>

Not sure if GRBL has something like that.

COMMAND REGEX you must set concretely as is responsed by GRBL. In Smoothie everything is responsed "ok" and proper regex to set is:

^ok.*

[Jason von Nieda]

With GRBL you don't typically need move complete regex. You normally just send G4P0 after a move, so the move_command looks like this:

G1XYZC (abbreviated)

G4P0

The G4P0 tells GRBL to return ok after all moves are complete.

Try that, and if you are still having problems, turn on debug logging and post a log showing a move. Also post your machine.xml.

Jason

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/79708567-c246-4e1d-803a-516526fa4f3d%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CA%2BKNHNytj%2BeLHFHmWNFZ2abRQ2M8GU2zqfQ3TkVtN6iEqrCH9Q%40mail.gmail.com.

[bert shivaan]

Thanks Jason, still had issues even with the G4P0. but then I turned command timeout up to 50000 and it will work. here is the log output, first I clicked "pick a part" then "discard" then H1:A1 on/off

2018-09-14 11:34:40 ReferenceHead DEBUG: H1.moveToSafeZ(0.98)
2018-09-14 11:34:40 ReferenceNozzle DEBUG: N1.moveToSafeZ(0.98)
2018-09-14 11:34:40 ReferenceNozzle DEBUG: N2.moveToSafeZ(0.98)
2018-09-14 11:34:40 ReferenceCamera DEBUG: OpenPnpCaptureCamera.moveToSafeZ(0.98)
2018-09-14 11:34:40 ReferenceActuator DEBUG: A1.moveToSafeZ(0.98)
2018-09-14 11:34:40 ReferenceCamera DEBUG: moveTo((200.251578, 178.030556, NaN, 0.000000 mm), 0.98)
2018-09-14 11:34:40 GcodeDriver DEBUG: sendCommand(G0 X200.2516 Y178.0306   F980, 50000)...
2018-09-14 11:34:40 GcodeDriver DEBUG: sendCommand(COM2 G0 X200.2516 Y178.0306   F980, 50000) => [ok]
2018-09-14 11:34:40 GcodeDriver DEBUG: sendCommand(G4P0, 50000)...
2018-09-14 11:35:04 GcodeDriver DEBUG: sendCommand(COM2 G4P0, 50000) => [md, ok]
2018-09-14 11:35:04 ReferenceCamera DEBUG: moveTo((200.251578, 178.030556, 0.000000, 0.000000 mm), 0.98)
2018-09-14 11:35:05 ReferenceHead DEBUG: H1.moveToSafeZ(0.98)
2018-09-14 11:35:05 ReferenceNozzle DEBUG: N1.moveToSafeZ(0.98)
2018-09-14 11:35:05 ReferenceNozzle DEBUG: N2.moveToSafeZ(0.98)
2018-09-14 11:35:05 ReferenceCamera DEBUG: OpenPnpCaptureCamera.moveToSafeZ(0.98)
2018-09-14 11:35:05 ReferenceActuator DEBUG: A1.moveToSafeZ(0.98)
2018-09-14 11:35:05 ReferenceNozzle DEBUG: N1.moveTo((200.067860, 174.872206, 0.000000, 171.689719 mm), 0.98)
2018-09-14 11:35:05 GcodeDriver DEBUG: sendCommand(G0 X200.0679 Y174.8722  C171.6897 F980, 50000)...
2018-09-14 11:35:05 GcodeDriver DEBUG: sendCommand(COM2 G0 X200.0679 Y174.8722  C171.6897 F980, 50000) => [ok]
2018-09-14 11:35:05 GcodeDriver DEBUG: sendCommand(G4P0, 50000)...
2018-09-14 11:35:26 GcodeDriver DEBUG: sendCommand(COM2 G4P0, 50000) => [md, ok]
2018-09-14 11:35:26 ReferenceNozzle DEBUG: N1.moveTo((200.067860, 174.872206, 0.000000, 171.689719 mm), 0.98)
2018-09-14 11:35:26 ReferenceNozzle DEBUG: N1.pick()
2018-09-14 11:35:26 GcodeDriver DEBUG: sendCommand(M800.1, 50000)...
2018-09-14 11:35:26 GcodeDriver DEBUG: sendCommand(COM2 M800.1, 50000) => [ok]
2018-09-14 11:35:26 ReferenceNozzle DEBUG: N1.moveToSafeZ(0.98)
2018-09-14 11:35:41 ReferenceHead DEBUG: H1.moveToSafeZ(0.98)
2018-09-14 11:35:41 ReferenceNozzle DEBUG: N1.moveToSafeZ(0.98)
2018-09-14 11:35:41 ReferenceNozzle DEBUG: N2.moveToSafeZ(0.98)
2018-09-14 11:35:41 ReferenceCamera DEBUG: OpenPnpCaptureCamera.moveToSafeZ(0.98)
2018-09-14 11:35:41 ReferenceActuator DEBUG: A1.moveToSafeZ(0.98)
2018-09-14 11:35:41 ReferenceNozzle DEBUG: N1.moveTo((0.000000, 0.000000, 0.000000, 0.000000 mm), 0.98)
2018-09-14 11:35:41 GcodeDriver DEBUG: sendCommand(G0 X0.0000 Y0.0000  C0.0000 F980, 50000)...
2018-09-14 11:35:41 GcodeDriver DEBUG: sendCommand(COM2 G0 X0.0000 Y0.0000  C0.0000 F980, 50000) => [ok]
2018-09-14 11:35:41 GcodeDriver DEBUG: sendCommand(G4P0, 50000)...
2018-09-14 11:36:06 GcodeDriver DEBUG: sendCommand(COM2 G4P0, 50000) => [md, ok]
2018-09-14 11:36:06 ReferenceNozzle DEBUG: N1.moveTo((0.000000, 0.000000, 0.000000, 0.000000 mm), 0.98)
2018-09-14 11:36:06 ReferenceNozzle DEBUG: N1.place()
2018-09-14 11:36:06 GcodeDriver DEBUG: sendCommand(M9, 50000)...
2018-09-14 11:36:06 GcodeDriver DEBUG: sendCommand(COM2 M9, 50000) => [ok]
2018-09-14 11:36:06 ReferenceNozzle DEBUG: N1.moveToSafeZ(0.98)
2018-09-14 11:36:18 ReferenceActuator DEBUG: A1.actuate(true)
2018-09-14 11:36:18 GcodeDriver DEBUG: sendCommand(M800.1, 50000)...
2018-09-14 11:36:18 GcodeDriver DEBUG: sendCommand(COM2 M800.1, 50000) => [ok]
2018-09-14 11:36:20 ReferenceActuator DEBUG: A1.actuate(false)
2018-09-14 11:36:20 GcodeDriver DEBUG: sendCommand(M9, 50000)...
2018-09-14 11:36:20 GcodeDriver DEBUG: sendCommand(COM2 M9, 50000) => [ok]

To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+unsubscribe@googlegroups.com.

To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/79708567-c246-4e1d-803a-516526fa4f3d%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+unsubscribe@googlegroups.com.

To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CA%2BKNHNytj%2BeLHFHmWNFZ2abRQ2M8GU2zqfQ3TkVtN6iEqrCH9Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to the Google Groups "OpenPnP" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+unsubscribe@googlegroups.com.

To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CA%2BQw0jy%3DtJiJYke-8OyrVVnfw0X6Ou2iCYkg-KBC2hxQpvXLrQ%40mail.gmail.com.

[bert shivaan]

So maybe the issue is simply I don't have GRBL setup correctly and it takes virtually 25 seconds to move 200mm?

[Jason von Nieda]

There are a lot of strange things in your config. I think you need to clean it up / simplify it a bit and try again.

You have a M800.1 in your Default MOVE_TO_COMMAND, and a M800.2 in your N1 MOVE_TO_COMMAND, and I don't see G4P0 anywhere in the config.

I recommend the following:

1. Select Default MOVE_TO_COMMAND and change it to:

G0 {X:X%.4f} {Y:Y%.4f} {Z:Z%.4f} {Rotation:C%.4f} F{FeedRate:%.0f}

G4P0

2. Select N1 MOVE_TO_COMMAND and clear it out.

3. Change COMMAND_CONFIRM_REGEX to ^ok.*; that's caret ok period asterisk.

Try a 10mm movement. If it is indeed taking dozens of seconds, fix your Grbl config, or, as you said, increase the timeout to a very large value. That's not nominal though - normally a full move across the table should take less than a few seconds.

Additionally, are you running a modified Grbl that supports the C axis? If not, that may be the source of the problems since Grbl will not understand the C token in G0.

And once again, finally, I will mention that Grbl is a bad choice for OpenPnP and you should not use it :)

Jason

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/79708567-c246-4e1d-803a-516526fa4f3d%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CA%2BKNHNytj%2BeLHFHmWNFZ2abRQ2M8GU2zqfQ3TkVtN6iEqrCH9Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CA%2BQw0jy%3DtJiJYke-8OyrVVnfw0X6Ou2iCYkg-KBC2hxQpvXLrQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CA%2BKNHNxfb1L8Z%2BfRnkm5DD0_8Rc8r-YOrFOyCCiONS6MGutbZg%40mail.gmail.com.

[Олег Перевышин]

G0 {X:X%.4f} {Y:Y%.4f} {Z:Z%.4f} {Rotation:C%.4f} F{FeedRate:%.0f} - Why is the feed rate indicated here?

At G0, the feedrate is ignored. Or am I not understanding something.

[Jason von Nieda]

It's fine to switch to G1, but as far as I know Grbl, Smoothie, and others all treat G0 and G1 the same. At least they did last time I checked - maybe it's changed. But yes, fine to use G1 too.

On Fri, Sep 14, 2018 at 11:04 AM Олег Перевышин <oleg.pe...@gmail.com> wrote:

G0 {X:X%.4f} {Y:Y%.4f} {Z:Z%.4f} {Rotation:C%.4f} F{FeedRate:%.0f} - Why is the feed rate indicated here?

At G0, the feedrate is ignored. Or am I not understanding something.

--

You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/7c27e447-4fe0-4ca3-9ef4-1a266a8ff018%40googlegroups.com.

[Marek T.]

GRBL has one serious advantage over Smoothie - let run the motion with step up to 400kHz (Smoothie only 100kHz). But in fact - not many need it to be so fast.

If you switch to Smoothie (or clone, but be warned about MKS) - you will get much better support here for sure.

[Олег Перевышин]

I think it's better to use G1, as per the standard.

пятница, 14 сентября 2018 г., 19:05:19 UTC+3 пользователь Jason von Nieda написал:

[bert shivaan]

Sorry for the strange XML file. I didn't realize it wasn't up to date with current session. I have made the changes and the behaivor is the same. I don't think this is anything more than not having GRBL setup correctly.

Just so I don't appear completely off, the odd commands you were seeing was me trying to figure out what was happening where. With different commands the error message would let me know what was trying to happen ie N1 move command or DEFAULT move command and so forth.

The G4P0 was actually in my setup, just not saved to the XML file I guess. Doe it only save on exit?

Tried the G1 instead of G0, same thing - takes approx 2 sec to move 10mm, so it is linear and I am sure has something to do with things like steps per mm and so forth.

I am using the GRBL with C axis as found in openPNP Docs.

I realize lots of folks are using Smoothie, but hard for me to pass up on a $10 mega for a >$100 controller.

I would love to know what the actual issues are with GRBL so I will be able to deal with them as they come up.

Until then I will just press on, mechanical side almost done then it will be all twidling bits to get running. :)

To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+unsubscribe@googlegroups.com.

To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/79708567-c246-4e1d-803a-516526fa4f3d%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+unsubscribe@googlegroups.com.

To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CA%2BKNHNytj%2BeLHFHmWNFZ2abRQ2M8GU2zqfQ3TkVtN6iEqrCH9Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+unsubscribe@googlegroups.com.

To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CA%2BQw0jy%3DtJiJYke-8OyrVVnfw0X6Ou2iCYkg-KBC2hxQpvXLrQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+unsubscribe@googlegroups.com.

To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CA%2BKNHNxfb1L8Z%2BfRnkm5DD0_8Rc8r-YOrFOyCCiONS6MGutbZg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to the Google Groups "OpenPnP" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+unsubscribe@googlegroups.com.

To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CA%2BQw0jzDqXxkkSmr86ztyHTTqZUd1QrfB1bQAC80fbi4Ag_UuQ%40mail.gmail.com.

[bert shivaan]

had a go at getting speeds up, looks like I am at about 4.5 seconds for 100mm. being all imperial sizes and what not that is about 53 ipm. That seems slow to me, pretty sure I had my foam cutter running at about 100ipm actual speed. I will keep messing about to see if i can get better, but does anyone know if this seems right?

(OK I have VMC's that run 1000ipm rapids, but those are really big A/C motors)

[Marek T.]

100mm in 4.5sec?

I don't know what the motors you have but some turtles seems be faster ;)

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/79708567-c246-4e1d-803a-516526fa4f3d%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CA%2BKNHNytj%2BeLHFHmWNFZ2abRQ2M8GU2zqfQ3TkVtN6iEqrCH9Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CA%2BQw0jy%3DtJiJYke-8OyrVVnfw0X6Ou2iCYkg-KBC2hxQpvXLrQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CA%2BKNHNxfb1L8Z%2BfRnkm5DD0_8Rc8r-YOrFOyCCiONS6MGutbZg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

[bert shivaan]

actually no motors connected yet.

That number is based on sending 100mm jog command to the control and getting finished response 4.5 seconds later. I have played with GRBL settings to make it this fast. Likely I will ask some GRBL people about this later. Before I do I will get motors connected and see if this is really the case.

Yes I think it is slow also, I cut alum at 6000 rpm full slot 1/2 inch mill .25 deep at 60 ipm every day.

So to think thats my rapid is odd.

To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+unsubscribe@googlegroups.com.

To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/095f3156-85c5-455f-ab3f-b9c17dd568ea%40googlegroups.com.

[Marek T.]

Understand.
More normal (for me) speed is like 0.5-1m/s.
However the speed can be limited with zipper to the speed like you said, and works with no timeouts.

[bert shivaan]

WOW!! 1m/s is screaming!! thats 2,362 inches per min

is this stepper or servo? if stepper how many steps per mm?

What drives?

What motion controller?

I am just curious is all.

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+unsubscribe@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/bb54d4d9-cf22-49e2-8de2-69726ae334e4%40googlegroups.com.

[Mark]

60m/min nicsssse!

[bert shivaan]

I could only hope for those speeds!!

I have gotten mine much better this morning. my accel was WAY too low. So now I am maybe somewhere in the 100mm/s speed. Of course my testing method is crude, I send a 100mm jog command and watch for reply in log window. This is a little crude for sure, but results are real even if not perfectly accurate.

On Sat, Sep 15, 2018 at 5:46 AM, Mark <ma...@makr.zone> wrote:

60m/min nicsssse!

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+unsubscribe@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/043701d44cd9%2401cb4560%240561d020%24%40makr.zone.

[Marek T.]

It's old retrofitted Philips machine with DC servo 150V motors.
Smoothieboard with some shity dc servo controllers.

[bert shivaan]

servos make sense for sure

I am thinking about my "shared Z" and "shared C" do I really need to worry about that? Seems like if oPNP sends a Z position, my control will move the Z stop to it, then the correct nozzle valve gets fired and all is good? Same for the C, why does it matter that all the nozzles turn? seems like if I want to use nozzle 3 at 45degrees, send g0C45, then place for nozzle 3. next send g0c0 and place nozzle 1 for nozzle 1 at 0 degrees?

What am I missing here? Of course X,Y will be adjusted for each nozzle.

On Sat, Sep 15, 2018 at 6:29 AM, Marek T. <marek.tw...@gmail.com> wrote:

It's old retrofitted Philips machine with DC servo 150V motors.
Smoothieboard with some shity dc servo controllers.

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+unsubscribe@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/c00d8364-d985-43ea-9537-3ab528d2fe5e%40googlegroups.com.

[Marek T.]

Openpnp picks 6 parts (if six nozzles are in use configured) and go with each one after one to the bottom camera to align them getting new C value. After allignment each nozzle remains in new position and goes to the place points to place them. By the way rotates them additionally for the angles related to the feeder storing angles and final rotation on board. Does not do last step if you turn on option "rotate prior to vision" - then does this step before alignment.
So Openpnp doesn't have to remember last reachef C angles if has separate motor for each nozzle.

If you have one C motor for every nozzles, OpenPNP must store each last calculated position to recall it just before place point. Because each new allign destroys the one done a moment before when changing C to new value. It's rather clear, isn't it?

Peter Benz head uses one Z motor shared for two nozzles. One nozzle comes down then second goes up. It needs modified Smoothieboard firmware made by Peter's efforts. I don't know how much it is necessary because never interested in it.

My modification of Openpnp to get shared-C uses Z angles to store C angles (it was made so because was relatively simple to realize and I don't use Z-motors).
So if you need Z motors then my mod will be not too useful for you.
Note I'm not the guy who could modify it for your requirements (not skills).
So probably you may need to worry a little...
Start learning Java...

[ma...@makr.zone]

> I am thinking about my "shared Z" and "shared C" do I really need to worry about that? Seems like if oPNP sends a Z position, my control will move the Z stop to it, then the correct nozzle valve gets fired and all is good? Same for the C, why does it matter that all the nozzles turn? seems like if I want to use nozzle 3 at 45degrees, send g0C45, then place for nozzle 3. next send g0c0 and place nozzle 1 for nozzle 1 at 0 degrees?

OpenPNP (the GcodeDriver actually) will omit an axis move if it thinks it is already at the correct angle. This may prevent shared C from working (maybe this is resolved elsewhere in the code?).

        if (rotationAxis != null && rotationAxis.getCoordinate() != rotation) {
                includeRotation = true;
        }

This could be fixed, if it is an issue, I guess. Other than that I see no obstacle.

Having seen some comments on this list to that effect (and not speaking from experience), you need to make sure that large parts don't slide on the nozzle tip when rotated back and forth, as this will happen after bottom vision.

_Mark

[Jason von Nieda]

There are two issues with shared C:

1. As others have mentioned, if two tools share an axis and the target position is the same no movement will happen. This is easily circumvented by adding a Rotation head offset to the nozzle. Even a head offset of 0.000001 will do the trick since when OpenPnP calculates the target position it will be different, so it will send the move.

2. The bigger issue, as Marek has mentioned, is that pre-rotate bottom vision, which most people want to use, doesn't work with shared C. If you don't have much nozzle runout you can run without this and it's fine, but most people want it. 

Jason

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.

To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/6c060e7e-8673-4081-86dc-fbf9205f4d7f%40googlegroups.com.

[Marek T.]

Hi Jason,
You have surprised me now.
As far as I know, openPNP does not work with shared-C at all but need jobProcessor modification. While when the modification is applied it works with the pre-rotate without problems.

[Jason von Nieda]

I've not personally tested it, but I can't think of why it wouldn't work. As far as I know the only issue is the limitation of GcodeDriver not sending the move, but adding a tiny head offset will fix that. I'll give it a try later on if no one beats me to it :)

Jason

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/6c3d2759-1bd6-47e9-a200-b5c28f3cbb2f%40googlegroups.com.

[Marek T.]

Now I feel totaly confused! It's Sat tonite here and maybe too much beer (at my side) ;).
Let's forget prerorate.
Does really openPNP serve shared-C?? Setup with ie 3 nozzles and one motor to drive their C-rotation? Or we talk something else about maybe?

[Jason von Nieda]

I took a look, and I was mistaken. It looks like the rotation offset would not be applied, so that will cause problems. The issue is in Location.subtract, since it ignores rotation offsets. I'll have to think about that a bit. We could probably fix it with a simple one line change in GcodeDriver. In any case, there is no need to modify JobProcessor for this. JobProcessor doesn't care about axes - only nozzles. It just expects a Nozzle commanded to go to a position to go to that position.

Jason

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/b0a86c2f-fbd7-4df6-83ad-b9a7fe940eaf%40googlegroups.com.

[Marek T.]

Probably I'm mistaken about the file where need to fix it.
When I'm at the PC I'll shoot you PM how have this done. And this work for me with and without the prerotate (with killing Z penalty). You know who made it for me.

If you'll find an idea how to fix it better and include to the regular release to have this more universal - great. If not - no big deal if it goes about me only (anyway I need to customize official releases because of some other things).

[Jason von Nieda]

I think we can fix this just by adding a "SharedCTransform" for the axis system that adds the tiny offset. Shouldn't require any modifications aside from the addition of a tiny new class. I'll give it a try in a few hours.

Jason

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/6957570e-33c1-4ea3-82d4-c9088b5779d6%40googlegroups.com.

[Marek T.]

Ok, if you do it I'll test it on my machine with real common-C motor machine.

[bert shivaan]

ok couple of thoughts here,

1 if the c is not shared, then I assume something like c1,c2,c3,c4 is sent to the motion controller to move each to an absolute position?

       If true, the the motion controller need only ignore the index and rotate c for each position sent. (Of course you can only place 1 part at a time, but really thats all you could do anyway.)

2> So maybe the way it works is when pre rotate is on, each nozzle gets rotated to the target postion then correction is added for board mis alignment then when looked at with bottom camera it is final corrected?

      If true that makes sense to me why there is a problem, no rotation command is sent when placing the part. Hmmm, is that what Jason is talking about?

My only experience is with my Dymaxon, it took a pick of all six nozzles as they passed the camera, then rotation was done at placment time. Yes it was a problem if nozzle is bent.

3) seems like the option to pre rotate to position over the camera and store that number for each, then when going to place just move C to the position found for the part being placed.

      Is this what the SharedCTransform" is about?

For my Z, the way it works is a single motor moves a common stop up and down, This stop is what determines how low the nozzle goes when actuated. I think I can handle that by either defining all my Z'z as just Z (no Z1,Z2,etc) or have my motion controller ignore the index. Mind you I am not sure how any motion control handles names such as Z1, to me it would see that as one unit (inch,mm,whatever). But I will watch and learn on that also.

On Sat, Sep 15, 2018 at 6:51 PM, Marek T. <marek.tw...@gmail.com> wrote:

Ok, if you do it I'll test it on my machine with real common-C motor machine.

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+unsubscribe@googlegroups.com.

To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/c28acb4c-b50d-43af-a8bc-8d3548a150f7%40googlegroups.com.

[ma...@makr.zone]

On Sunday, September 16, 2018 at 12:32:38 AM UTC+2, Jason von Nieda wrote:

I think we can fix this just by adding a "SharedCTransform" for the axis system that adds the tiny offset. Shouldn't require any modifications aside from the addition of a tiny new class. I'll give it a try in a few hours.

Jason, are you sure?

If I'm not mistaken (looking at the code) it stores the final transformed "raw" coordinate on the Axis object. That is one separate Axis object for each nozzle. So each of the Axis objects stores their own current coordinate.

So if one of the shared axes turns, the others will not know it and they will still think they are at the last coordinate/angle. If one of them is later commanded to turn to the same angle that it already has stored, the coordinate will be wrongfully swallowed.

The proposed "SharedCTransform" will not help, as it is always applied "privately" to that axis and again no change would be detected from the last move.

BTW I wondered about the same issue for shared Z too. With bad luck some Z moves will be swallowed too. It's probably just because nozzles do their pecking solo and always return to safe Z before the other nozzle moves, that this issue has not shown so far.

Remedy: issue all coordinates to the machine, regardless of whether OpenPNP thinks a coordinate has changed or not.

Having looked at several controllers' source code (Smoothieware, Prusa, Marlin, G2), I know they will always optimize away zero deltas on their own. No need for OpenPNP to be doing that.

If there are other reasons for this, perhaps a second set of G-code MOVE_TO_COMMAND coordinate variables could be introduced, that are always issued:

X! Y! Z! Rotation!

_Mark

[bert shivaan]

Thanks Mark, Now I see the reason. oPNP thinks each nozzle is in position, so no command is sent.

Maybe another solution instead of sending all rotation commands even if the same, can we have a setting to say "shared C" then if true update the current C for each nozzle when other C moves are made? That way when it comes time to place nozzle 4, oPNP will know nozzle 4 is now in position of last C move?

Another possibility maybe, assuming the planner knows the order of nozzle placement, ie N1,N5,N2.N3, the current position could be stored as the position of the nozzle used before it. So N6 current is =N1, N2 current is = N5 and so forth. Then a move is always required.

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+unsubscribe@googlegroups.com.

To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/e53623c4-9258-4e0d-bc31-772891646ec0%40googlegroups.com.

[Mark]

> … if true update the current C for each nozzle when other C moves are made?

 

No, I don’t think this would be good.

 

Note that OpenPNP sends moveTo() commands to different objects of the machine, so-called “Moveables” i.e. the camera, the nozzles, etc.. Then depending on what it is, the proper axis mapping takes place (and an offset is applied). Because of the axis mapping, the different Z1, Z2, … and C1, C2, …  axes come into play on multi-nozzle machines.

 

You want each axis/nozzle to remember the current angle independently, because OpenPNP often tells a nozzle “move in X, Y but keep rotation as is”. So with shared C axes this would actually correctly restore the specific nozzle rotation, if the JobProcessor switched from a different nozzle. Because of that–although Jason seems to think differently–I see no reason why pre-rotate would not work correctly.

 

However there is the bug I described earlier. If you know how to build OpenPNP, you could just change these lines of code here

https://github.com/openpnp/openpnp/blob/ab456b503aba10b1d7c9a4f9be22cc5f5de131fd/src/main/java/org/openpnp/machine/reference/driver/GcodeDriver.java#L571

 

        if (rotationAxis != null && rotationAxis.getCoordinate() != rotation) {

                includeRotation = true;

        }

into

        if (rotationAxis != null) {

                includeRotation = true;

        }

 

to test this.

 

Personally I don’t have a multi-nozzle machine, so I can’t test this reasonably. You would help us, if you did. If this works, we could then find a solution that works for all users. Perhaps with the suggestion I made earlier.

 

_Mark

 

[bert shivaan]

When I can I am more than happy to test this Mark. There are a few action items items on my end to work out first.

1- get machine running to test it on. (I thin I should have an operational machine by the end of the week if all goes well)

2- Learn how to use oPNP enough to build a board (seems pretty easy thus far, this are pretty intuvitave I think)

3- prolly build my first job using single nozzle (needed to build a board and my old machine quit on me. Thus the reason I am here (actually happy it happened now, just bad timing))

4- learn how to build oPNP and make the changes suggested by you

5- Finally be able to test it.

This will likely take me a few weeks to get through all above. But I do welcome the chance to give back to this awesome project!!!

In the meantime maybe Marek can give it a whirl on his machine?

-Bert

--

You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+unsubscribe@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/048801d44db8%2416ca1290%24445e37b0%24%40makr.zone.

[Marek T.]

First, I think it's better to wait for Jason's opinion. Because finally he's the one who will decide which kind of solution to apply to the official release.
Second, anything to test I can perform after Oct.3 only. This week have no machine accessible to any experiments (still busy on some jobs), next week I'm on some holidays.

[Mark]

Cool.

 

Just realized I sent you the wrong „build“ link (Hardware instead of Software). The correct one is this one:

https://github.com/openpnp/openpnp/wiki/Developers-Guide#building-openpnp

 

_Mark

 

[Mark]

Note that the quick change I proposed is just to test locally on Bert's machine. The official solution will not be that simple, because it has to work with all users and should not change behaviour.

 

_Mark

 

-----Ursprüngliche Nachricht-----
Von: ope...@googlegroups.com [mailto:ope...@googlegroups.com] Im Auftrag von Marek T.
Gesendet: Sonntag, 16. September 2018 15:10
An: OpenPnP
Betreff: Re: [OpenPnP] Re: Is this one of the GRBL bugs?

 

First, I think it's better to wait for Jason's opinion. Because finally he's the one who will decide which kind of solution to apply to the official release.

Second, anything to test I can perform after Oct.3 only. This week have no machine accessible to any experiments (still busy on some jobs), next week I'm on some holidays.

 

--

You received this message because you are subscribed to the Google Groups "OpenPnP" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.

To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/3826d0da-c9c9-4fe7-aaf8-b843187e2d04%40googlegroups.com.

[bert shivaan]

no problem on the link, I noticed that (read it anyway)

Found the developers guide and giving it a read. I have been avoiding that link on purpose so I can keep my focus on the task at hand (build something to build my current board. Once I complete that I am going to dig deeper for sure. I think this is prolly one of the best projects I have seen, and the only for pick and place machines. I hope to be around for a good while. :)

On Sun, Sep 16, 2018 at 9:13 AM, Mark <ma...@makr.zone> wrote:

Note that the quick change I proposed is just to test locally on Bert's machine. The official solution will not be that simple, because it has to work with all users and should not change behaviour.

 

_Mark

 

-----Ursprüngliche Nachricht-----
Von: ope...@googlegroups.com [mailto:openpnp@googlegroups.com] Im Auftrag von Marek T.

Gesendet: Sonntag, 16. September 2018 15:10
An: OpenPnP
Betreff: Re: [OpenPnP] Re: Is this one of the GRBL bugs?

 

First, I think it's better to wait for Jason's opinion. Because finally he's the one who will decide which kind of solution to apply to the official release.

Second, anything to test I can perform after Oct.3 only. This week have no machine accessible to any experiments (still busy on some jobs), next week I'm on some holidays.

 

--

You received this message because you are subscribed to the Google Groups "OpenPnP" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+unsubscribe@googlegroups.com.

To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/3826d0da-c9c9-4fe7-aaf8-b843187e2d04%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to the Google Groups "OpenPnP" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+unsubscribe@googlegroups.com.

To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/04a401d44dbf%240371a9e0%240a54fda0%24%40makr.zone.

[Marek T.]

So still more better to wait for Jason :-).
His proposal for sure will be universal only.

The only problem is the time when he may do that... It's only one of the many personal requests waiting to realize not the serious common bug. So I'll be really surprised if see this quick.

[bert shivaan]

I will test the above, as maybe this will be helpful overall as Mark said.

I suppose if I am really motivated I could save the different Cx positions in the motion controller when they are sent. then in the place command I could send something that tells the controller to rotate to C position for the nozzle being placed.

Maybe this should be a controller side solution anyway?

Hmm, food for thought

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+unsubscribe@googlegroups.com.

To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/a308c3ac-561b-4814-8d06-2eb61fc23473%40googlegroups.com.

[Jason von Nieda]

Hi Mark,

Sadly, you are mistaken. Just as in shared Z (see-saw configuration) there is only one axis. It's best to think of an axis as a motor. In the shared Z one motor (axis) controls the Z coordinates of two nozzles. The raw coordinate is the real coordinate of the motor, while the coordinate that OpenPnP sees is the transformed coordinate.

Anyway, as I said, should be easy to test. Working on it now. Stand by :)

Jason

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/e53623c4-9258-4e0d-bc31-772891646ec0%40googlegroups.com.

[Jason von Nieda]

Okay, here it is: https://github.com/openpnp/openpnp/commit/f8c9f2d06aca57fd841761ebf99bd842525c5c49

Add to machine.xml like this:

            <axis name="c" type="Rotation" home-coordinate="0.0">

               <head-mountable-ids class="java.util.HashSet">

                  <string>N1</string>

                  <string>N2</string>

                  <string>N3</string>

               </head-mountable-ids>

               <transform class="org.openpnp.machine.reference.driver.GcodeDriver$OffsetTransform">

                  <offsets-by-head-mountable-id>

                     <entry>

                        <string>N1</string>

                        <double>1.0E-4</double>

                     </entry>

                     <entry>

                        <string>N2</string>

                        <double>2.0E-4</double>

                     </entry>

                     <entry>

                        <string>N3</string>

                        <double>3.0E-4</double>

                     </entry>

                  </offsets-by-head-mountable-id>

               </transform>

            </axis>

Tested with this script, which moves each of three nozzles to the "same" position:

load(scripting.getScriptsDirectory().toString() + '/Examples/JavaScript/Utility.js');

var imports = new JavaImporter(org.openpnp.model, org.openpnp.util);

with (imports) {

task(function() {

var n1 = machine.defaultHead.getNozzle("N1");

var n2 = machine.defaultHead.getNozzle("N2");

var n3 = machine.defaultHead.getNozzle("N3");

var location = new Location(LengthUnit.Millimeters, 10, 10, 10, 10)

n1.moveTo(location);

n2.moveTo(location);

n3.moveTo(location);

});

}

And here's the result:

2018-09-16 09:30:50 ReferenceNozzle DEBUG: N1.moveTo((10.000000, 10.000000, 10.000000, 10.000000 mm), 1.0)

2018-09-16 09:30:50 GcodeDriver DEBUG: sendCommand(G0 X10.0000 Y10.0000 Z10.0000 C9.9999 1000, 5000)...

2018-09-16 09:30:50 GcodeDriver DEBUG: sendCommand(serial:///dev/tty.usbmodem1A12421 G0 X10.0000 Y10.0000 Z10.0000 C9.9999 1000, 5000) => [ok]

2018-09-16 09:30:50 ReferenceNozzle DEBUG: N2.moveTo((10.000000, 10.000000, 10.000000, 10.000000 mm), 1.0)

2018-09-16 09:30:50 GcodeDriver DEBUG: sendCommand(G0    C9.9998 1000, 5000)...

2018-09-16 09:30:50 GcodeDriver DEBUG: sendCommand(serial:///dev/tty.usbmodem1A12421 G0    C9.9998 1000, 5000) => [ok]

2018-09-16 09:30:50 ReferenceNozzle DEBUG: N3.moveTo((10.000000, 10.000000, 10.000000, 10.000000 mm), 1.0)

2018-09-16 09:30:50 GcodeDriver DEBUG: sendCommand(G0    C9.9997 1000, 5000)...

2018-09-16 09:30:50 GcodeDriver DEBUG: sendCommand(serial:///dev/tty.usbmodem1A12421 G0    C9.9997 1000, 5000) => [ok]

Thanks,

Jason

[ma...@makr.zone]

On Sunday, September 16, 2018 at 4:04:53 PM UTC+2, Jason von Nieda wrote:

Hi Mark,

Sadly, you are mistaken. Just as in shared Z (see-saw configuration) there is only one axis. It's best to think of an axis as a motor. In the shared Z one motor (axis) controls the Z coordinates of two nozzles. The raw coordinate is the real coordinate of the motor, while the coordinate that OpenPnP sees is the transformed coordinate.

Hi Jason

darn...just looked at

https://github.com/openpnp/openpnp/wiki/GcodeDriver:-Axis-Mapping#axis-transforms

more closely and I see. :(

What happens if you actually declare multiple axes in the machine.xml and use AxisMapping on these? To have more than one of a type is what the "type" attribute is for, right? (that actually threw me)

At the top of MoveTo() there's the call to getAxis(). This would return a different Axis object for each of the rotation axes mapped to the different nozzles, right?

Then add the PR I just made... well this is probably for the bin.

https://github.com/openpnp/openpnp/pull/766

_Mark

[Jason von Nieda]

Multiple axes of the same type is when you have multiple motors for the same "type" of axis. The most common configuration that uses this is... non-shared C :) In other words, when you have a separate motor for each C axis on each nozzle you end up with one axis per nozzle. Here's an example of what I'd say is the most common config in the OpenPnP world:

         <axes class="java.util.ArrayList">

            <axis name="x" type="X" home-coordinate="0.0">

               <head-mountable-ids class="java.util.HashSet">

                  <string>*</string>

               </head-mountable-ids>

            </axis>

            <axis name="y" type="Y" home-coordinate="250.0">

               <head-mountable-ids class="java.util.HashSet">

                  <string>*</string>

               </head-mountable-ids>

            </axis>

            <axis name="z" type="Z" home-coordinate="0.0">

               <head-mountable-ids class="java.util.HashSet">

                  <string>N1</string>

                  <string>N2</string>

               </head-mountable-ids>

               <transform class="org.openpnp.machine.reference.driver.GcodeDriver$CamTransform" cam-radius="24.0" cam-wheel-radius="9.5" cam-wheel-gap="2.0">

                  <negated-head-mountable-id>N2</negated-head-mountable-id>

               </transform>

            </axis>

            <axis name="rotation1" type="Rotation" home-coordinate="0.0">

               <head-mountable-ids class="java.util.HashSet">

                  <string>N1</string>

                  <string>C1</string>

               </head-mountable-ids>

               <pre-move-command><![CDATA[T0]]></pre-move-command>

            </axis>

            <axis name="rotation2" type="Rotation" home-coordinate="0.0">

               <head-mountable-ids class="java.util.HashSet">

                  <string>N2</string>

               </head-mountable-ids>

               <pre-move-command><![CDATA[T1]]></pre-move-command>

            </axis>

         </axes>

In this, Z is shared (see-saw config) and the two nozzles each have their own stepper motor to turn the nozzle. So, one motor for Z, two motors for two Cs. One axis for Z, two axes for two Cs.

I'll take a look at the PR. Ultimately I think your way will be better since it doesn't modify the coordinates that get sent. 10 is nicer looking than 9.9999 :) The only reason the GcodeDriver works the way it does now, where it doesn't send unchanged coordinates, is due to some bug in either Grbl or Marlin - I can't remember which. One of them would choke on zero deltas. There's a good chance that that bug no longer exists, so it's possible we could just remove the fix altogether, but the PR will do nicely.

Jason

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/a0c6d76b-5e9b-4177-91d5-fac3dd472d33%40googlegroups.com.

[ma...@makr.zone]

Hi Jason

on second thought... now I'm confused.

If the getCoordinate() refers to a single shared internal C Axis object, why is your change then needed at all?

If C2 moves to an angle, this is recorded in the shared C Axis.coordinate member. If subsequently C1 wants to be at a different angle, it will detect a difference and include the coordinate in the Gcode.

Also I noticed my PR still makes sense but for different reasons, such as when Z-probing, adding relative moves (as currently nedeed for proper vacuum sensing), etc. whenever OpenPNP loses track of the physical coordinate.

_Mark

[ma...@makr.zone]

On Sunday, September 16, 2018 at 4:53:32 PM UTC+2, Jason von Nieda wrote:

Multiple axes of the same type is when you have multiple motors for the same "type" of axis...

Yes, but is there anything speaking against using multiple Axes objects it for shared C?

You can use the same axis designator in the Gcode MOVE_TO_COMMAND so it would just actuate the same "motor". Also it seems that AxisTransform can be used as well, if needed. The current coordinate would then be recorded and retained per nozzle.

Using my PR, these coordinates would be properly restored switching back and forth between Nozzles.

This way pre-rotate would work, right?

_Mark

 

[Jason von Nieda]

That all sounds right to me, but maybe we need to restate the problem. I'm not sure I understand if the pre-rotate problem is different from the shared C movement problem. I'm going to start a new thread and post some background on both issues and we can see if this, or other changes, will fix one or both. I think we've polluted Bert's thread enough :)

 

If the getCoordinate() refers to a single shared internal C Axis object, why is your change then needed at all?

If C2 moves to an angle, this is recorded in the shared C Axis.coordinate member. If subsequently C1 wants to be at a different angle, it will detect a difference and include the coordinate in the Gcode. 

Also a good question - I think the problem isn't when it wants to move to a different angle - it's when it want to move to the same angle on a different nozzle but that angle is different at the hardware level. But now I'm not sure sure. Let's move to the new thread and see if we can suss this all out.

Jason

 

_Mark

 

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/95c5c850-0766-49bb-bdee-d8a3b2e3c4f2%40googlegroups.com.

[Mark]

> see if we can suss this all out.

 

“suss”? Nice to learn a new word every day J

 

_Mark