Advanced Search

This is confusing, why stepconfig?
Stepconfig is for parallel port setups, only.

Hi...I have a mechanical home switch wired as seen from others but does not seem to be functioning...I am not sure I have hal right for x home switch...I have pin # 2  from mesa 7196s going to nc on switch...Input common to 24v ground on  power supply  and switch common to 24v power supply v+...I am not very good with electric so any help would be greatly appreciated..

Thanks,
Rick

Any suggestions would be appreciated.
Thanks
 

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