Advanced Search

Works great for me.
Pushed.

Thanks

Just an FYI, Mesa cards make network jitter much less of an issue.

Thank you, MikkelRS, edited my previous post to reflect the correction.

About 10Mb, 423469 lines
Run at 2010, don't remember with which version but went fine

An update for what it is worth.........
LinuxCNC XYYZ (gantry) up and running, at least without hardware attached. i.e reporting parallel port pin status with the Hal Watch. All seems to function as expected. HAL config still brain numbing though.
Had to drop back to V2.7 to get a reasonable jitter number on my old Athlon X2 CPU. (20,000)
No network connection but USB stick for file transfer is OK albeit clunky. 

Phil

I am working on a custom LinuxCNC UI and trying to understand whether EMC_TASK_PLAN_STEP can be given reliable “step completed” answer using only public LinuxCNC command/status/error channels.

The goal is not to step exactly one authored G-code source line. I understand LinuxCNC native step mode appears to operate on internal interpreter/motion boundaries, and these may not map 1:1 to G-code lines. Multiple G-code lines may combine into one motion item, and some lines such as modal changes or dwell may not produce motion identity changes.

What I am looking for is a public NML/status signal that reliably answers:

“The requested native step has reached its terminal boundary.”

I tested the following using command/status/error NML:

EMC_TASK_PLAN_STEP
EMC_TASK_PLAN_RUN
EMC_TASK_PLAN_PAUSE
EMC_TASK_PLAN_RESUME
EMC_TASK_PLAN_RUN from a specified line
status fields including task mode/state, interpreter state, exec state, task_paused, EMC_STAT.motion.traj.single_stepping, motion_line, current_line, read_line, motion_id, in-position, active file, command echo/serial, and the error channel.

Observed behavior:

EMC_TASK_PLAN_STEP in AUTO submits and echoes reliably.
EMC_TASK_PLAN_STEP in MANUAL also writes/echoes, then reports asynchronously through the error channel: can't do that (EMC_TASK_PLAN_STEP:511) in manual mode.
From idle/AUTO, the first PLAN_STEP appears to arm/pause state but does not expose line or motion advancement.
From paused queued motion, repeated PLAN_STEP can advance motion_line / motion_id, which is useful for motion items.
For dwell/non-motion cases, I did not find a reliable public line/motion/status transition that identifies completion of one native step.
EMC_STAT.motion.traj.single_stepping is public and useful, but it seems to represent persistent stepping mode/gate state. It can remain true after observed motion or non-motion boundaries, so it does not by itself delimit one requested step.
RUN -> PAUSE and RESUME -> PAUSE expose reliable running/paused transitions, but the amount of program read/queued/executed before pause takes effect is not bounded enough to call it a STEP.
RUN(line) -> PAUSE chooses a start line but does not provide a next-boundary terminal condition.

Looking at LinuxCNC task behavior, it seems the more precise native step gate may involve internal state such as steppingWait and steppedLine, but I do not see those exposed through public status.

My questions:

Is there an existing public NML/status field, Python linuxcnc.stat() field, or other supported API that indicates completion of one native EMC_TASK_PLAN_STEP request?
Is EMC_STAT.motion.traj.single_stepping intended only as a persistent stepping-mode flag, or can it be interpreted with other public fields to detect a completed native step?
Are steppingWait, steppedLine, or equivalent native step-boundary state intentionally private, or is there another public way to observe that same information?
For UI purposes, is it correct to expose EMC_TASK_PLAN_STEP only as a raw/native LinuxCNC step command without promising source-line or  completion?
Is there a recommended command/status sequence used by AXIS, QtDragon, or other UIs to decide when a single native step has completed?

At this point, my conclusion is that PLAN_STEP can be exposed as a native control, but I should not claim reliable completion unless LinuxCNC exposes a per-request step boundary or stepped identity through public status. I would appreciate confirmation or correction from anyone familiar with the task/interpreter stepping internals.

Also, I wish there were a 'developer' forum where I could ask questions like these

CSM, Compatibility Support Module, which helps newer bios's boot older styles of OSs.

Thanks for your reply. I will try it in the morning. Can you tell me what CMS is?

Check the BIOS, disable "secure boot" if enabled.
Might also need to enable "CMS" as the PC might refuse to boot.
Edit:
Should be CSM, not CMS.

Hey, tested your proposal for panning/zooming => works nice!
 

7I97T config with 7I74 on expansion port with 8 BISS absolute encoder interfaces:


 

 

The preview window has a similar problem to the Vismach. There's no limit at all to the maximum and minimum zoom. You can zoom in infinitely without any visual effect, and the same applies to zooming out. There's also a tweak to the s value, which doesn't work linearly with zooming in and out, and at certain zoom levels, moving left, right, and up is difficult.

I'm uploading the corrected glnav.py.
Please try it out.

For now, the world is silent. Maybe it's not so bad...

I am trying to install LCNC (debian12) onto a new second hand Dell desktop. I have copied configuration files across. but when I try to start the software I am getting this error:
iopl() failed: Operation not permitted
cannot gain I/O privileges - forgot 'sudo make setuid' or using secure boot? -parallel port access is not allowed
Note: Using POSIX realtime
Linux parallel port 0 not found
hal_parport: rtapi_app_main: No such file or directory (-2)
./4_Axis_Mill.hal:6: waitpid failed /usr/bin/rtapi_app hal_parport
./4_Axis_Mill.hal:6: /usr/bin/rtapi_app exited without becoming ready
./4_Axis_Mill.hal:6: insmod for hal_parport failed, returned -1
4976
Stopping realtime threads
Unloading hal components
iopl() failed: Operation not permitted
cannot gain I/O privileges - forgot 'sudo make setuid' or using secure boot? -parallel port access is not allowed
Note: Using POSIX realtime
Any Help gratefully received
Thanks

I used to work in an environment that required high reliability. Hot-swap spares were the norm and that includes software. If you were updating software, it was done on a second (or sometimes even third) device to ensure that you always had 1 working production device and often a working spare as well. This philosophy is required in some industries, but many have moved away from it due to the cost. For a long time, downtime was forbidden. Now consultants or MBAs model the cost of downtime and can often justify it as critical savings in the short term. My local hospital recently rolled out a software update that brought down all their OR suites for over a week due to a driver issue.

I've been using Debian (and offshoots) for over 20 years and *nix before that. Original sysadmins were taught the importance of backups before updates as the OS itself doesn't provide a mechanism to roll back. There is an opportunity to provide better instructions to users on how to migrate a system safely, but it is a lot of work and there is always some risk.

I have linuxcnc running in a NixOS VM for simulations and might move my main controller to this one day.