Pick and place dwell times in seconds not milliseconds ?

[f...@ltec.ch]

My system (LitePlacer, TinyG, OpenPNP V 2.6) was working fine the last time I used it (some months ago). Since then I have just update the OS (Kubuntu 24.04.5 LTS).

When I started using the system today I observed extremely long pick and place dwell times. Further investigations have shown that these times are now 'executed' in units of seconds instead of milliseconds!

When picking a component it takes 1'40" (100 seconds instead of 100 milliseconds) and when placing a component it takes 3'20" (200 seconds instead of 200 milliseconds).

Any idea why all of a sudden milliseconds are 'executed' as seconds?

many thanks and kind regards, Felix

[Jorropo]

What is the DELAY gcode set to in your gcode driver setting ?

--
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 view this discussion visit https://groups.google.com/d/msgid/openpnp/e68a6019-50fe-40e4-8235-20a5c53e8de3n%40googlegroups.com.

[f...@ltec.ch]

The DELAY_COMMAND looks like this:

{TimeMS:G4 P%d} ; Delay for given time in [ms]

Frankly I never touched it and I think it's default.

[Jan]

Hi Felix!
COMMAND_DELAY is optional. If not set (for any controller), Javas
Thread.sleep() is used (which requires coordination, which is the reason
why DELAY was introduced).
Please consult your logs at trace level: you'll find "delay
Thread.sleep" or "gcode delay sent" (or some other combination of
"gcode" and "delay"). Then you can check the generated gcode (you'll
have to enable the option "Log G-code?" on the Driver Settings tab of
your GCodeDriver.) thats send to your controller.

Jan

On 25.09.2026 09:32, 'f...@ltec.ch' via OpenPnP wrote:
> My system (LitePlacer, TinyG, OpenPNP V 2.6) was working fine the last
> time I used it (some months ago). Since then I have just update the OS
> (Kubuntu 24.04.5 LTS).
>
> When I started using the system today I observed extremely long pick and
> place dwell times. Further investigations have shown that these times
> are now 'executed' in units of seconds instead of milliseconds!
>

> pick-place-dwell-times.png
>
> When picking a component it takes 1'40" (100 seconds instead of 100
> milliseconds) and when placing a component it takes 3'20" (200 seconds
> instead of 200 milliseconds).
>
> Any idea why all of a sudden milliseconds are 'executed' as seconds?
>
> many thanks and kind regards, Felix
>

> --
> 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

> <mailto:openpnp+u...@googlegroups.com>.

> To view this discussion visit https://groups.google.com/d/msgid/openpnp/

> e68a6019-50fe-40e4-8235-20a5c53e8de3n%40googlegroups.com <https://
> groups.google.com/d/msgid/openpnp/
> e68a6019-50fe-40e4-8235-20a5c53e8de3n%40googlegroups.com?
> utm_medium=email&utm_source=footer>.

[f...@ltec.ch]

From what I can see in the trace (G-Code tracing enabled), OpenPNP does everything absolutely correct.

Entering manually a G-Code G4 P100 followed immediately by a G1 X10 results in the machine waiting for 100 seconds before moving 10 mm on the x-axis.

It looks like my Tiny-G board interprets the G4 parameter P100 as 100 seconds instead of 100 milliseconds as it usually did. What could have changed this behavior and how can I fix it?

[Jan]

Hi Felix!
You'll need to lookup the exact syntax for TinyGs G4 command and it's
arguments. OpenPnP is prepared to substitute the delay value in either
milliseconds using "TimeMS" (as you do) as well as in seconds using
"TimeSeconds". Both support dot notation allowing e.g. millisecond
accurate timing if expressed in seconds.

Jan

On 25.09.2026 11:04, 'f...@ltec.ch' via OpenPnP wrote:
> From what I can see in the trace (G-Code tracing enabled), OpenPNP does
> everything absolutely correct.

> Entering manually a G-Code *G4 P100* followed immediately by a *G1 X10*

> openpnp/ <https://groups.google.com/d/msgid/openpnp/>
> > e68a6019-50fe-40e4-8235-20a5c53e8de3n%40googlegroups.com
> <http://40googlegroups.com> <https://
> > groups.google.com/d/msgid/openpnp/ <http://groups.google.com/d/
> msgid/openpnp/>
> > e68a6019-50fe-40e4-8235-20a5c53e8de3n%40googlegroups.com
> <http://40googlegroups.com>?
> > utm_medium=email&utm_source=footer>.

>
> --
> 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
> <mailto:openpnp+u...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/

> openpnp/1062f443-e7d1-41d5-892b-24a3d1a86e2an%40googlegroups.com
> <https://groups.google.com/d/msgid/openpnp/1062f443-
> e7d1-41d5-892b-24a3d1a86e2an%40googlegroups.com?
> utm_medium=email&utm_source=footer>.

[f...@ltec.ch]

First of all: many thanks for your help! It has pushed me into the right direction.

Looking up TinyG's G4 command clearly states that its parameter uses seconds (not milliseconds) and there seems to be no setting to change that.

Hence I have ended up with removing the optional COMMAND_DELAY and using Javas Thread.sleep() as you described Jan. Things are now working fine again - as they did before.

The only mystery remaining is: how and when did that COMMAND_DELAY G-Code got defined? I have definitely no memory at all being the author of that command. This will probably simply remain a mystery ;-).

once more, many thanks for all your help, Felix

[simpl...@tuta.io]

Hi, have your tested fractional seconds?

[Clemens Koller]

Hello, Felix!

Be aware that the Tiny-G can sometimes get very confused when it's feed with too much
configuration changes at a time ($-commands)... since AFAICT while writing to permanent
memory, there is no protection from overflowing the command buffer (despite having
hardware or software handshaking).

So, I was doing all $-configuration before starting OpenPnP in a dedicated startup
procedure.

In the meanwhile I migrated my heavily modified Liteplacer over to a Duet3D 6HC controller.

Regards,

Clemens

On 9/25/26 11:04 AM, 'f...@ltec.ch' via OpenPnP wrote:
> From what I can see in the trace (G-Code tracing enabled), OpenPNP does everything absolutely correct.

> Entering manually a G-Code *G4 P100* followed immediately by a *G1 X10* results in the machine waiting for 100 seconds before moving 10 mm on the x-axis.

> > To view this discussion visit https://groups.google.com/d/msgid/openpnp/ <https://groups.google.com/d/msgid/openpnp/>

> > e68a6019-50fe-40e4-8235-20a5c53e8de3n%40googlegroups.com <http://40googlegroups.com> <https://
> > groups.google.com/d/msgid/openpnp/ <http://groups.google.com/d/msgid/openpnp/>
> > e68a6019-50fe-40e4-8235-20a5c53e8de3n%40googlegroups.com <http://40googlegroups.com>?
> > utm_medium=email&utm_source=footer>.
>

> --
> 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 <mailto:openpnp+u...@googlegroups.com>.

> To view this discussion visit https://groups.google.com/d/msgid/openpnp/1062f443-e7d1-41d5-892b-24a3d1a86e2an%40googlegroups.com <https://groups.google.com/d/msgid/openpnp/1062f443-e7d1-41d5-892b-24a3d1a86e2an%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Jan]

Hi Felix!
The command was likely suggested by I&S. There is no distinction
between controllers yet.
@all: may I ask for your suggestions: what command shall I&S suggest
here? "G4 P<milliseconds>" for Smoothie only (V1 and V2 seems to support
this) and "G4 P<seconds>" for others?

Jan

> msgid/ <https://groups.google.com/d/msgid/>
> > openpnp/ <https://groups.google.com/d/msgid/openpnp/ <https://
> groups.google.com/d/msgid/openpnp/>>
> > > e68a6019-50fe-40e4-8235-20a5c53e8de3n%40googlegroups.com
> <http://40googlegroups.com>
> > <http://40googlegroups.com <http://40googlegroups.com>> <https://
> > > groups.google.com/d/msgid/openpnp/ <http://groups.google.com/d/
> msgid/openpnp/> <http://groups.google.com/d/ <http://
> groups.google.com/d/>
> > msgid/openpnp/>
> > > e68a6019-50fe-40e4-8235-20a5c53e8de3n%40googlegroups.com
> <http://40googlegroups.com>
> > <http://40googlegroups.com <http://40googlegroups.com>>?

> > > utm_medium=email&utm_source=footer>.
> >
> > --
> > 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
> > <mailto:openpnp+u...@googlegroups.com>.
> > To view this discussion visit https://groups.google.com/d/msgid/

> <https://groups.google.com/d/msgid/>
> > openpnp/1062f443-e7d1-41d5-892b-24a3d1a86e2an%40googlegroups.com
> <http://40googlegroups.com>
> > <https://groups.google.com/d/msgid/openpnp/1062f443- <https://
> groups.google.com/d/msgid/openpnp/1062f443->
> > e7d1-41d5-892b-24a3d1a86e2an%40googlegroups.com

> <http://40googlegroups.com>?
> > utm_medium=email&utm_source=footer>.
>
> --
> 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
> <mailto:openpnp+u...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/

> openpnp/293dccfa-79c9-4a2c-8e1b-cf0039721370n%40googlegroups.com
> <https://groups.google.com/d/msgid/openpnp/293dccfa-79c9-4a2c-8e1b-
> cf0039721370n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[f...@ltec.ch]

Yes, but this did not work.

[Jan]

Would you please elaborate?
I've prepared a PR that now suggests "{TimeSeconds:G4 P%d}" as
COMMAND_DELAY. This shall fix the issue for you.
Ok it shall probably read "P%.f"...

Jan

> --
> 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
> <mailto:openpnp+u...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/

> openpnp/8e2ac5c1-afbe-4afd-b2a4-a319fb9ca4ban%40googlegroups.com
> <https://groups.google.com/d/msgid/openpnp/8e2ac5c1-afbe-4afd-b2a4-
> a319fb9ca4ban%40googlegroups.com?utm_medium=email&utm_source=footer>.

[f...@ltec.ch]

For testing I have successively sent 10 times G4 P5 (no seconds fractions) followed by a G1 X10. As expected it took about 50 seconds for the nozzle before it started to move 10 mm along the x-axis.

Then I successively sent 10 times G4 P0.5 (no errors reported by TinyG) followed by a G1 X10. I would have expected the nozzle to start moving  after a delay of about 5 seconds 10 mm along the x-axis, but it intermediately began moving after entering the G1 X10 code. From that I concluded that the 10 G4 P0.5 commands were not 'understood' by the TinyG board and hence the TinyG board can not handle fractions of seconds.

If all I did and concluded is correct then the smallest dwell time 'executed' by a TinyG board is 1 second and the granularity of the G4 code on a TinyG board is also 1 second. 

[Jan]

Hm... thats very strange and unexpected...

On 25.09.2026 16:58, 'f...@ltec.ch' via OpenPnP wrote:
> For testing I have successively sent 10 times *G4 P5 *(no seconds
> fractions) followed by a *G1 X10*. As expected it took about 50 seconds

> for the nozzle before it started to move 10 mm along the x-axis.
>

> Then I successively sent 10 times *G4 P0.5* (no errors reported by
> TinyG) followed by a *G1 X10*. I would have expected the nozzle to start

> moving  after a delay of about 5 seconds 10 mm along the x-axis, but it

> intermediately began moving after entering the *G1 X10* code. From that
> I concluded that the 10*G4 P0.5* commands were not 'understood' by the

> TinyG board and hence the TinyG board can not handle fractions of seconds.
>
> If all I did and concluded is correct then the smallest dwell time
> 'executed' by a TinyG board is 1 second and the granularity of the G4
> code on a TinyG board is also 1 second.
>
> On Friday, September 25, 2026 at 4:32:07 PM UTC+2 Jan wrote:
>
> Would you please elaborate?
> I've prepared a PR that now suggests "{TimeSeconds:G4 P%d}" as
> COMMAND_DELAY. This shall fix the issue for you.
> Ok it shall probably read "P%.f"...
>
> Jan
>
> On 25.09.2026 14:27, 'f...@ltec.ch' via OpenPnP wrote:
> > Yes, but this did not work.
> >
> > On Friday, September 25, 2026 at 12:35:42 PM UTC+2
> simpl...@tuta.io wrote:
> >
> > Hi, have your tested fractional seconds?
> >
> >
> > --
> > 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
> > <mailto:openpnp+u...@googlegroups.com>.
> > To view this discussion visit https://groups.google.com/d/msgid/

> <https://groups.google.com/d/msgid/>
> > openpnp/8e2ac5c1-afbe-4afd-b2a4-a319fb9ca4ban%40googlegroups.com
> <http://40googlegroups.com>
> > <https://groups.google.com/d/msgid/openpnp/8e2ac5c1-afbe-4afd-
> b2a4- <https://groups.google.com/d/msgid/openpnp/8e2ac5c1-afbe-4afd-
> b2a4->
> > a319fb9ca4ban%40googlegroups.com?
> utm_medium=email&utm_source=footer <http://40googlegroups.com?
> utm_medium=email&utm_source=footer>>.

>
> --
> 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
> <mailto:openpnp+u...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/

> openpnp/208561ee-caab-4311-8cce-27f23d10e347n%40googlegroups.com
> <https://groups.google.com/d/msgid/openpnp/208561ee-
> caab-4311-8cce-27f23d10e347n%40googlegroups.com?
> utm_medium=email&utm_source=footer>.