Advanced Search

In master branch 2.10, there is a pin called motion.interp.line-number which is a real time reading of the line number.
As you pointed out some commands do not move the tool. These could be deduced from motion.interp.motion-type
Ref: linuxcnc.org/docs/devel/html/en/man/man9/motion.9.html

A change of line number reliably indicates the end of the motion segment.

I coded this and I don't think that a motion segment extends over multiple lines. However, the current position will deviate from the Gcode commanded position for a number of reasons. I saw this when testing where an arc was followed by a straight line. In this case, the path is blended to transition based on look ahead planning, G64 settings etc.

Briefly, Gcode lines are read into a tokenised buffer and discarded (eg an old fashioned circular buffer). Then the trajectory planner converts the buffer one entry at a time. A single line of code might take quite some time to execute so conversion can be hundreds of lines behind. Ref github.com/LinuxCNC/linuxcnc/blob/master...gc/interp_convert.cc

Until recently there was no way for motion to read interpreter data. But now each motion segment is tagged with the interpreter state when its converted. Ref: github.com/LinuxCNC/linuxcnc/blob/master...c/motion/state_tag.h

My motion.interp pins added additional fields to the state tags which are then decoded in real time in motion so the data changes on every tick of the servo thread.

Hope that helps.


 

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