For all those with M400 problems

[Bernd Walter]

For all those, for which M400 doesn't seem to work.
My CNC mill had been running on a custom build board and last year I've switched to a repetier firmware based board.
My old board was directly running via ethernet and the new one was used via Octoprint to run gcode files to the board.
But on my old board I had been using some individual tools, one of them specialized to peck drill holes.
Today I've converted that drill tool to speak to the new repetier board.
After each command I wait for the "ok" as OpenPnP does.
Now, just to not fill the machine buffer with too many commands, in case I want to stop, I've added an M400 after each hole.
This was very surprising, because the "ok" came directly after sending the command.
It was the next command, which had to wait for the "ok".
Obviously the firmware sends the ok when it received the command and not after execution.
To really wait for the machine to have reached it's final position I had to do two M400 commands.
I'm pretty sure it is not my software mixing up and errously using a previous "ok".
Nevertheless I will check up with the repetier firmware sourcecode and talk to them.
Now this might be a specific implementation issue with repetier firmware, but it got me to surprise and
maybe others might have similar implementation issues, especially since many of those 3D printer derived firmwares share
a common history.
So if in doubt do a second M400, just in case - beside some few extra bytes send, it won't really hurt.

[Jason von Nieda]

It is very easy to test this on a given firmware. Open up a terminal to talk to the controller and send it a long move at a very slow rate. Something like G1 X100 Y100 F10, hit enter to start the move and then immediately enter a M400 and hit enter. See if the "ok" happens immediately or if it happens when the move completes.

You can even do this in OpenPnP by using the jog controls and watching the log at TRACE level. The log includes timestamps for each string sent and received, so you can see how long it takes to receive the "ok" for the M400. 

Here's an example from my machine running Smoothie:

2017-07-02 16:26:10 GcodeDriver TRACE: [/dev/tty.usbmodem1A12411] >> G0 X102.5000    F2100 ; Send standard Gcode move

2017-07-02 16:26:10 GcodeDriver TRACE: [/dev/tty.usbmodem1A12411] << ok

2017-07-02 16:26:10 GcodeDriver TRACE: [/dev/tty.usbmodem1A12411] >> M400 ; Wait for moves to complete before returning

2017-07-02 16:26:13 GcodeDriver TRACE: [/dev/tty.usbmodem1A12411] << ok

You can see the first command sends the move (G0) and we get an "ok" less than a second later. Then we send the M400 within the same second and we don't get the second "ok" until 3 seconds later, when the move completes.

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/85f2ac74-ded6-464a-a0de-823693fc4c67%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Bernd Walter]

The repetier source is quite clear.
It sends the "ok" when the received line is "plausible" before it is actually processed.

[Jason von Nieda]

But the second M400 doesn't?

On Sun, Jul 2, 2017 at 4:32 PM Bernd Walter <be...@bwct.de> wrote:

The repetier source is quite clear.
It sends the "ok" when the received line is "plausible" before it is actually processed.

--
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/25e3b2aa-7899-4674-bbab-fe2474e1b443%40googlegroups.com.

[Bernd Walter]

On Sunday, July 2, 2017 at 11:34:26 PM UTC+2, Jason von Nieda wrote:

But the second M400 doesn't?

 The second works fine.

Repetier does the following.
parserloop calling GCode::readFromSerial()
readFromSerial parses the line into variables and if the parsing wents fine it sends ok.
At this point the first M400 already failed to ensure that the machine reached it's final position.
The parseloop calls a process m-code.
The m-code calls the wait function.
The wait function now takes over the serial to return a busy line from time to time.
Interestingy it also calls readFromSerial(), but some flags stops it from parsing the line.
Now when you send a second M400 you won't get an ok as long as the first M400 execution is stuck in the wait routine.
 

[Bernd Walter]

On Sunday, July 2, 2017 at 11:28:40 PM UTC+2, Jason von Nieda wrote:

It is very easy to test this on a given firmware. Open up a terminal to talk to the controller and send it a long move at a very slow rate. Something like G1 X100 Y100 F10, hit enter to start the move and then immediately enter a M400 and hit enter. See if the "ok" happens immediately or if it happens when the move completes.

You can even do this in OpenPnP by using the jog controls and watching the log at TRACE level. The log includes timestamps for each string sent and received, so you can see how long it takes to receive the "ok" for the M400. 

Here's an example from my machine running Smoothie:

2017-07-02 16:26:10 GcodeDriver TRACE: [/dev/tty.usbmodem1A12411] >> G0 X102.5000    F2100 ; Send standard Gcode move

2017-07-02 16:26:10 GcodeDriver TRACE: [/dev/tty.usbmodem1A12411] << ok

2017-07-02 16:26:10 GcodeDriver TRACE: [/dev/tty.usbmodem1A12411] >> M400 ; Wait for moves to complete before returning

2017-07-02 16:26:13 GcodeDriver TRACE: [/dev/tty.usbmodem1A12411] << ok

 

Yes - this is a save bet that Smoothie does the right thing.
I should add timestamps in my tools output too.

I don't know if smoothie has any history in other 3D printer firmware or if it was written from scratch.
AFAIK Repetier firmware has a history on GRBL - not much of it is left however.

[Jason von Nieda]

Just to be sure, I just flashed the latest Smoothie firmware to my Smoothieboard 5X.

Old version: Build version: edge-8f06510, Build date: Jun 16 2016 13:22:31, MCU: LPC1769, System Clock: 120MHz

New version: Build version: upstreamedge-b6153da, Build date: Jun 21 2017 21:02:36, MCU: LPC1769, System Clock: 120MHz 5 axis

And still get the same results:

2017-07-02 16:55:50 GcodeDriver TRACE: [/dev/tty.usbmodem1A12411] >> G0 X102.5000    F2100 ; Send standard Gcode move

2017-07-02 16:55:50 GcodeDriver TRACE: [/dev/tty.usbmodem1A12411] << ok

2017-07-02 16:55:50 GcodeDriver TRACE: [/dev/tty.usbmodem1A12411] >> M400 ; Wait for moves to complete before returning

2017-07-02 16:55:53 GcodeDriver TRACE: [/dev/tty.usbmodem1A12411] << ok

So I think for Smoothie, at least, we are safe :)

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/7a11cd64-8d1b-43ea-8c5e-0209a0f33acb%40googlegroups.com.