Advanced Search

if I go to V- instead of power supply ground IN2 lights...is that ok? or does it indicate a different problem?

I forgot about that.....no

Does the yellow LED near IN2 operate as expected?

Hi...I used pin that is labeled iN2....and put in Hal as GPIO 002....when I tried to test in Halshow nothing happened....i checked wiring seems ok....I did not know if i am missing something in Hal...I only put  info  in the x axis section...
.
# ---# external input signals...under this part it is blank..


setup home / limit switch signals---
net x-home-sw <=  hm2_7i96s.0.gpio.002.in_not
net x-home-sw <= joint.0.home-sw-in

Thanks for reply!!

TB3 pin Pin 2 would be GPIO 01 (but actually you should be using INM pins, not GPIO)

Pncconf setup would be something like:

 


(invert it using NC switches)

You should also use halshow to verify home switch operation before attemting to home

Ok, that makes sense, I deleted the step config file. Currently I can jog XYZ in the pnc config "test this axis" .
Gmoccapy  jog does not work but shows movement on screen.
Thanks
 

pb12 wrote:

Had to drop back to V2.7 to get a reasonable jitter number on my old Athlon X2 CPU. (20,000)
 

Very bad idea...
Wheezy with RTAI has low jitter on some motherboards, but today this is time waste only.
This is 32bit Linux, Python 2.7, no realtime ethernet, and old LinuxCNC not compatible with modern, even at configs level, so you get many useless experiences...

Yesterday I installed Debian13.5 with LinuxCNC 2.10 on my Lenovo M725s SFF Ryzen 3 8GB 128GB M.2 NVMe (not newest but still modern), jitter is 20,000 and all works well.
This model has LPT connector at motherboard, but you can buy cheap second hand PCIex to LPT card.
In my opinion, LPT is obsolete, but if exist, you can serve some auxilary signals by this.

There are cheap 7i92 clones on Aliexpress.
I have model similar to original MESA, and chinese version with I/O drivers, both works well.

In my opinion, the future is ethercat and modbus. 
This is more cost and more dificult, but works like in dreams...
 

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?