GUIs: read [DISPLAY]CYCLE_TIME with one rule

[grandixximo]

Fixes #4424.

At the 2026-09-13 meeting (#4497 item 3) it was agreed that every GUI/VCP first reads [DISPLAY]CYCLE_TIME the gmoccapy way: 0.001 <= value < 1.0 is seconds, value >= 1.0 is milliseconds, anything else warns and uses the default of 150 ms. Whether to move to a single unit later is a separate question and not part of this PR.

• New lib/python/common/cycle_time.py: display_cycle_time(inifile, warn) returns milliseconds and reports an invalid value through warn (stderr without a callback). AXIS, gmoccapy, gscreen, hal_glib.py (GladeVCP) and iniinfo.py (QtVCP, QtPlasmaC) call it.
• tklinuxcnc applies the same rule in Tcl. It used to multiply every value by 1000, so CYCLE_TIME = 100 gave a 100 s update period.
• stepconf writes CYCLE_TIME = 100 like pncconf (it wrote 0.100, same period).
• Docs state the one rule. The QtVCP example also had HALPIN_CYCLE where the code reads HALPIN_CYCLE_TIME.
• tests/display-cycle-time checks the boundaries (0.0009, 0.001, 0.5, 0.999, 1, 100, negative, zero, missing, non-numeric) without a running LinuxCNC.

Behaviour changes:

• The default is 150 ms everywhere. Configs without CYCLE_TIME change: AXIS was 20 ms, QtVCP, GladeVCP and gscreen 100 ms, tklinuxcnc 200 ms.
• gscreen accepts seconds and values below 50 ms, which it used to replace with 100 ms.
• Invalid values (zero, negative, below 0.001, non-numeric) warn. Before, AXIS, QtVCP and GladeVCP turned 0.0005 into a 0 ms timer and a negative value into a negative one.

Tested with runtests tests/display-cycle-time tests/ui-smoke/{axis,gmoccapy,qtdragon}, and by starting AXIS, tklinuxcnc and gscreen under xvfb with valid and invalid values.

[rene-dev]

I would much prefer the unit to be seconds, at least for all new configurations.

[c-morley]

All (peetty sure) the gui toolkits use ms not seconds. I would prefer not to do the conversion and at least to me 100 is a much simpler and easier to read number then .1

[rene-dev]

But the unit isn't in the configuration, and a lot of different units are used throughout Linuxcnc. We are in the process of unifying them, and seconds is the SI base unit and just makes sense to use for everything.

[grandixximo]

You were not at the meeting (#4497 item 3), so for context: there was no full agreement on the unit. What was decided is that both keep working and the configs drift towards one of them. @rene-dev argued for seconds, and the others were in favour or did not mind, so this PR moves what the tree writes to seconds and still reads ms.

The contrast that came up was [TASK]CYCLE_TIME: same name, in seconds. Nobody at the meeting was sure it still did anything. I checked, and it does: it sets the period of task's main loop (emctaskmain.cc). Seconds is also the unit the INI is built on, since every velocity and acceleration on the joints and axes is per second.

The toolkits taking ms is internal: the shared reader converts once, and 100 keeps working in any config, so nothing changes for anyone who prefers it.

[rene-dev]

That is exactly what Im talking about, having different units for everything is really confusing for the user, especially if you need to compare them. Everything else is in terms of seconds, doesn't matter what the underlying system uses. Im sure you don't write gcode in encoder counts ;)

[c-morley]

Are you going to change the servo period to seconds then?

Why not use the unit that makes the most practical sense?
The user is not going to change the cycle time to tune anything except in weird circumstances - it's just a number to them. 100 and 50 are easier then .1 and .05

I also don't like axis DEFAULT_LINEAR_JOG_VEL in seconds for the same reason. Machinists think in unit per minute not unit per second.

I did the work to change it to ms so as not to break configs but move to ms.
I spoke to Norbert about what he preferred at the time, we agreed.

I understand your thought process but but that's not how human think. They use the unit that makes most sense for the process your are talk of.

But in the end.. I've said my point - change it to whatever you like.

[grandixximo]

I am a human, and when I see this

[TASK]
CYCLE_TIME=0.01

[DISPLAY]
CYCLE_TIME=100

I just think, why? I mean I know why, but why?

lol

jokes apart, the user facing ms still works, and if you like that better you can keep using it, this is mostly about internal consistency, and new users not getting confused about what the units are for CYCLE_TIME

If we go ms, I think TASK CYCLE_TIME should also change to ms, and possibly get the same logic when less than 1 actually is seconds, to not break all the configs out there...

I'll keep this open, but not merge it, and let the discussion evolve, I hear you Chris :-)