OpenPNP on LitePlacer (TinyG) - Timeout when doing small moves

[JL GV]

Hello, I am running the software on my liteplacer using G code driver and I am having issues with small movements timing out with the message "timed out waiting for move to complete".

I saw someone mention this problem but no solution was offered.

Any idea how to fix this?

Thanks.

[Jason von Nieda]

Hi JL, is it possible you sent the wrong log there? I don't see any move complete timeouts, but I do see an enable timeout. If you have a log that shows the move timeout that will help me diagnose.

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/91656f32-b635-44a9-bc79-3ac41a34f039%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[JL GV]

Oops, here is a log where at the end there are some timeouts:

[JL GV]

BTW. I have 2 small contributions so far. For the tiny G controller, I found sometimes it would enter json mode on startup even though it's disabled. This was fixed by sending a $ME in the connect Gcode as shown in the logs. Also, there is a bug in the example configuration for TinyG here: https://github.com/openpnp/openpnp/wiki/TinyG I

The bug is that the axis E should be replaced with A. See my machine.xml for what I mean.

[Jason von Nieda]

Thanks JL, this reminded me that we had seen something like this before. I went back and did some research and there are a few things we can try.

First, try setting status reports to include the stat keyword:

tinyg> {sr:{line:t,posx:t,posy:t,posz:t,vel:t,unit:t,stat:t}}

And turn on unfiltered automatic status reports:

tinyg> $sv=2

Then let's change your MOVE_TO_COMPLETE_REGEX to ".*stat:3.*" (minus the quotes).

Let me know if that changes things for you. 

The core issue seems to be that TinyG is failing to send good status reports for very small moves unless the moves are done very slowly. I think the issue is really that it's only sending status reports every 250ms and if the move takes less than that it won't send one. 

LitePlacer actually uses a bit of a hack to handle this. It hardcodes F200 for small moves so that they move slow enough to allow some status reports. Unfortunately the generic nature of the GcodeDriver makes this type of hack difficult. 

My hope is that we can convince TinyG to send a final status report in all cases, in which case monitoring for stat:3 (stopped) should work in all cases.

If we can't make that happen, it's probably time to take this issue to the TinyG folks and ask what the best way to handle this would be. 

Finally, I just noticed that we can request a status report by sending {"sr":null}, so it could be that the solution is to have the driver send this during the wait for moves to finish. This would be a relatively easy change to make, so if it comes down to it this can be fixed in OpenPnP pretty easily.

Reference Material:

https://github.com/synthetos/g2/issues/138

https://github.com/synthetos/g2/issues/139

https://github.com/synthetos/TinyG/wiki/TinyG-Status-Reports

https://github.com/synthetos/TinyG/wiki/TinyG-Status-Codes

https://groups.google.com/d/msg/openpnp/j-TAyyZ9XQ0/NIl9ZUNnBwAJ

Jason

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/476e5887-f7a2-4a84-9c79-9ff68168fcd8%40googlegroups.com.

[JL GV]

Wow you're good. That fixed it. Here are my logs for reference. I can now queue 0.1mm and 1mm commands as fast as I can click without problem. Will write back if I experience this problem again.

Thanks so much. Looking forward to contributing to this project as I learn my way around.

Jonathan.

Search engine terms: OpenPNP tinyG Timeout when doing small moves solution

[Jason von Nieda]

JL,

That's great news! Thanks for sending the log and machine.xml. Would you mind also sending your TinyG config? I'd like to update the Wiki page with this info.

Also, minor but it might bite you later, you added the MOVE_TO_COMPLETE_REGEX only for your nozzle, and not the default. Look at machine.xml and see that you have MOVE_TO_COMPLETE_REGEX defined twice. You should just have one and it should be:

         <command type="MOVE_TO_COMPLETE_REGEX">

            <text><![CDATA[.*stat:3.*]]></text>

         </command>

Note the head-mountable-id is not set, which makes this the default for all head objects.

Jason

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/18c71c0c-89f7-49ba-8e70-cf04d277c0b8%40googlegroups.com.

[JL GV]

Hi Jason. I have fixed that in machine.xml (and everything still works). However, I am wondering what dictates the list of available commands in the GUI? Because this MOVE_TO_COMPLETE_REGEX was not available for Default. See attached.

Also, my current tinyG settings are here, and the updated machine.xml.

Jonathan.

[Jason von Nieda]

JL, I think you just need to scroll down in the list to see it? I just checked my copy and it's there, towards the bottom.

Thanks for the settings and updated machine.xml, I will update the Wiki.

Jason

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/4e86abed-c447-4753-ad99-e95dfc2b3ffa%40googlegroups.com.

[JL GV]

Yes you are right, I didn't see the scroll bar on the right.

Jonathan.

[Juha Kuusama]

TinyG behavior in this case is speed settings depending. I stumbled on this when I first tested it. The discussion I had with the developer is here: https://www.synthetos.com/topics/g0-minimum-movement/

[Jason von Nieda]

Thanks for posting that Juha, that is very informative. I wonder if any change to this behavior was ever made. From where I sit it seems like a fairly glaring bug in TinyG to ignore a move in anticipation of a future move that may never come.

Jason

On Tue, Nov 8, 2016 at 11:44 PM Juha Kuusama <ju...@kuusama.com> wrote:

TinyG behavior in this case is speed settings depending. I stumbled on this when I first tested it. The discussion I had with the developer is here: https://www.synthetos.com/topics/g0-minimum-movement/

--
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/10fa974c-2805-4dc1-bd36-d8965f8c0eaa%40googlegroups.com.

[JL GV]

Hello all.

It seems the TinyG sometimes looses some settings on reboot, so my suggestion is to put all the required settings in the "connect" field in the gCode editor.

For example, on my unit $sv became 1 again inexplicably.

Jonathan.

[Jason von Nieda]

Jonathan,

Would you mind sending your final, working machine.xml? I am updating the documentation and I'd like to make sure I've remembered all the pieces.

Thanks,

Jason

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/35f74e67-8529-4df3-bf60-4992dddc9f0a%40googlegroups.com.

[JL GV]

Here it is Jason.

Jonathan.

[Jason von Nieda]

Thank you!

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/1702c883-1cfd-4bef-a92a-2ac1747040f2%40googlegroups.com.