Advanced Search

I had the same issue with shipping/duty. I purchased a 7i96s and I don’t regret it.

rhscdn wrote:

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

Yep...... and as I want to understand and experiment with cnc a Mesa card (or Ethercat device) would be the way to go. I was definitely considering a Mesa card (7i96)
I do have another more capable PC. Would need an ethernet card for Mesa. Or parallel port card. Or ethernet card + Mesa for my old Athlon X2 (2 core) hardware
Freight is the killer USD80 just to get a Mesa card to my country.
Many decisions ..............

Phil

tommylight wrote:

I would really appreciate if someone else would write something about this, and i will gladly delete this.

Anyone?

I agree there is potentialy risk in upgrade an working machine.
I like have newest system with newest abilities, so I upgrade/install system very often.
Sometimes there is no problems, sometimes system or Linuxcnc became useless...
My last bad experience is MESA "error finishing read" error after upgrade kernel (some versions of 6.12 kernel works well, some not).
The best solution is full backup and two or few disks with many partitions.
The Debian 13 with LinuxCNC installed only for control the machine (xfce4, no CAD/CAM etc.) fits in 8 GB disk space.
It is only a few minutes for copy whole of that partition with dd...

In other side, I know the man who has above twenty (!!!) commercial (!!!) installations of Wheezy on very old commputers with LPT ports.
If you don't know what it means, I explain : 32bit systems with RTAI kernel (no realtime ethernet) with hardware in end of their life...
Any updates of this museum are imposible, and any old configs will not work with modern LinuxCNC... 

Thanks Rod,

A few months ago I mentioned that I was working on an experiment to add a C++ interface layer for LinuxCNC UIs. The lower layer wraps LinuxCNC’s NML command/status channels and HAL polling, and then a higher-level controller layer sits on top of that to coordinate UI commands, wait for observable LinuxCNC state changes, and avoid treating command writes or echoes as completion. The same core can then support a local Node/N-API (or Python) UI and a WebSocket interface for remote clients, as long as those clients route machine-control actions through that higher-level command layer rather than bypassing it with raw NML calls.

As part of this, I am trying to make the higher-level UI commands report completion only when LinuxCNC has actually reached an observable machine/controller state, rather than when a command write succeeds or when command echo advances. For example, cycle start, pause, resume, stop, program load/reload, override changes, spindle state, WCS selection, and touch-off can all be treated this way because there is some later status observation that confirms the requested result.

`EMC_TASK_PLAN_STEP` is the current problem child. I do not want to say “step completed” merely because `PLAN_STEP` was accepted or echoed. I would prefer some public status/HAL indication that the requested native step has reached its end/completion.

Your suggestion about `motion.interp.line-number` and `motion.interp.motion-type` was helpful. The pins do exactly what you described for motion segments. They track the trajectory planner’s executing interpreter metadata, distinguish arc/linear motion, and in my probe they updated slightly ahead of the corresponding NML `motion_line` / `motion_id` fields. In an arc-followed-by-line test, the line/type changed at the blended segment boundary, which is very useful for execution display and diagnostics.

However, I do not think they solve the general completion problem for native STEP. In dwell or other non-motion STEP cases, `motion.interp.line-number` and `motion.interp.motion-type` did not change, so I still could not distinguish a completed non-motion native step from waiting, arming, or stale motion metadata. In an invalid MANUAL `PLAN_STEP` case, the command still wrote/echoed, the HAL interp pins stayed stale, and the asynchronous error channel was still required to detect the rejection.

So my current conclusion is:

* `motion.interp.*` is very useful for showing the currently executing motion segment.
* It is better timed than the NML motion-line fields in some cases.
* It does not appear to provide a per-request completion signal for `EMC_TASK_PLAN_STEP`.
* It does not cover dwell/non-motion interpreter items.
* It does not replace the error channel for rejected step requests.

For a UI that claims “STEP completed,” I think I would still need LinuxCNC to expose something closer to a public stepped-item sequence, stepped-line identity, or native step gate-closure signal that covers both motion and non-motion interpreter items.

Does that match your understanding of how `PLAN_STEP`, `steppingWait`, `steppedLine`, and the motion state tags fit together? Or is there another public field or HAL pin I should be watching for the non-motion STEP cases?

Apoligies for the long post - but I have been looking at panels for my upcoming LCNC retrofit and lo and behold, a cheap used Haas keypad came up. So, was wondering if there's still life in this project? Has anyone managed to map the whole (or most) of the keypad by now?

And here comes the wordy part:
Actually, I had to ask the AI overlords to explain why making the keypad work on LCNC is such a challenge. And it seems mapping it is the easy part and can possibly be done with some sniffer code. Once mapped, passing on button presses as USB HID is doable, too - and more so with the right MCU. But then there's a bit of an issue in that HID is pretty strict and wont pass on CNC-specific "characters". But a gamepad library would (as generic button numbers) and you could run two of them (HID + gamepad) on the same, newer MCU over just one USB connection. (Oh, turns out the two-protocol approach is AI's idea. Here, in the forum, it was proposed to use funky combo presses for the CNC buttons).

So far, so good? (If AI is correct on all of this). But then the real issue is, it's actually safer and much preferred to run this with Smart Serial and bypass the LCNC host computer and instead talk to the Mesa cards directly? But that protocol is not open, right?

Personally, I think I am OK with the USB method or a sort of hybrid - I could split a handful of more important controls out and run them direct to Mesa DIs and keep the rest over USB. Wouldn't that be OK? And if so, is it correct that the USB method is pretty doable, but perhaps the project stranded on Smart Serial access?

OK, so the reason I am trying to wrap my head around all this is that I also see a lot of other used panels apart from the Haas (I tap into the used market in Asia). Some of them may be locked down as I see some more fancy chips on the PCBs but some are just a "dumb" matrix. And for some of the locked own ones, they could possibly be rewired as a matrix. And some of them are so cheap and pretty neat, I might give this a go - but it would be nice to hear if what (A)I wrote above holds true. If it does, I think am up for it. 

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?