Advanced Search

Hi @rodw, @Hakan and everyone,
Thanks a lot for the input — this is really helpful.
@rodw, your barebone CiA402 state handler is exactly what I needed to properly structure the lower layer. The statusword & 0x006F decoding and the minimal enable sequence up to Operation Enabled fit perfectly as a clean PDS manager.
@Hakan, yes — I’m now looking at splitting things one step further, exactly as you suggest.
The structure I’m converging to is:

1. PDS manager (CiA402 FSA layer)
   • Based on rodw’s barebone logic
   • Responsible only for bringing the drive from Switch On Disabled to Operation Enabled
   • No homing, no CSP logic inside
   • Exposes something like op_enabled
2. Op-mode layer (separate modules)
   • CSP
   • CSV
   • Homing
   • PP / PV
   • Probing, etc.
     Each module only runs when op_enabled == true and after 6060/6061 handshake is confirmed.
3. Application layer (drive-agnostic)
   • Homing bit4 pulse generation
   • done_mask / done_value evaluation
   • Error mask/value
   • All configurable via parameters (no hardcoded drive values)

The goal is to keep this fully drive-agnostic at the application level, using mask/value instead of fixed statusword comparisons.About the concern Hakan mentioned — “maybe switching op-modes and restoring position kills it” — I agree that’s the main trap.My current idea is:

• On mode entry: temporarily slave pos_cmd := pos_fb (freeze target) until the drive confirms the new mode via 6061
• Only then release control to avoid position jumps
• Same approach on exit back to CSP

So mode switching becomes edge-triggered and gated, not a live swap.
To make sure I’m not inventing behavior, I’m using these two documents as formal references for the machine state and execution semantics:

• CiA 402 – Part 2 (Operation Modes & PDS Finite State Automaton)
• PLCopen Motion Control – Part 1 (FB Model & State Diagram)

Right now I’m validating all of this in a pure SIM environment (drive stub + HAL components), before integrating back into real EtherCAT hardware.
Also, just a small note: during the week I mostly work on this code at my job — evenings are usually family time (kids at home), so progress sometimes comes in structured blocks rather than daily updates. But I’m moving forward steadily.
If anyone has suggestions on best practices for mode handover (especially CSP ⇄ Homing) or additional references worth reading, I’d really appreciate it. ​​​​​​[/code][/code][/b][/code][/b][/code][/i][/i][/b][/b][/i][/code]

Thanks! I just modified quickly linuxcnc to send exactly your data. But no F/S. So I think just a buggy firmware.

Here is updated nesting using sparrow algorithm. Im also including the github repo for anyone who wants to use the software or work on the software. If you make any changes you would like to share make a github and include them here and I will test and implement them into the main build. To build the software I am using claude code, pretty much just text to code dont have to be a genius just good at coming up with ideas a 20 dollar subscription to the ai and some free time on your hands. 
Here is the github link github.com/xxhalflifexx-source/plasmacam
since the start of writing this post I also added it so it can nest even tighter by rotating the parts at 1 degree increments, its honestly mostly on par as far as i can tell with industrial grade nesting software. but yea here u guys go, go wild. if you like the project put some time into improving it any way you can. 

 

One more update on display in Auto mode. NOW it does show F: and S:
and also coordinate updates.
After x minutes is seems to enter some sleep mode and stops updating the
display altogether. Buttons still work though.

I think I wrote that the component is prepared for reconnecting. No, it isn't.
If the setupAsyncTransfer() fails, the component exits.

I am testing to see if the usb part can be restarted. 


 

Got something done regarding the compensation with my own approach. How bad is the wear and are you getting any tapers?

Based on Acieras vtk vismach integration I've made a usertab for probe basic. The files are a drop in simulation config which should get you going. Credit for the code goes to Aciera. 

github.com/bildobodo/probe_basic_vtk_sim_gcode

 

Have you looked at splitting the function one more step?

state-machine (bringing to op-enabled) : One component
op-mode module: Several components, csp, csv, homing, pv, pp, probing etc.

Looks appealing at first thought. Maybe switching between op-modes
and restoring position kills it though

You can always test the new version. It is actually very easy to make a backup
of the eeprom contents and later put it back if needed.We need TwinCAT to do the translation from ESI file to eeprom binary contents.
While there are some open-source tools for that too, the safest way is to use TwinCAT.
 

with automatic nesting sheet metal tracking could be implemented pretty easily. keep track of ur scraps and steel inventory. set auto order to automatically send a email to the steel supply, would be pretty neat when it runs low.

Here is the first rendition of the nesting feature, needs alot more work but its starting to get rolling. would be pretty revolutionary to have free automatic nesting. 



 

Capture class:
github.com/Sigma1912/vtk-vismach/blob/main/vtk_vismach.py#L832

Plotter class:
github.com/Sigma1912/vtk-vismach/blob/main/vtk_vismach.py#L742

tool->work transformation matrix is calculated in the update() method:
github.com/Sigma1912/vtk-vismach/blob/main/vtk_vismach.py#L796


Works for me.

For an example on how to implement toolpath plotting in work coordinates using vtk see:
github.com/Sigma1912/vtk-vismach

'Capture()' embeds an invisible actor in the model that can then be used to track the transformation matrices for the tooltip and the work which can then be used to plot the toolpath.

Yes, You are absolutely right. Vismach is not important at all. I also think so. Thats why really few persons are using this.
If you can just give me initial lead which files I should look for? I tried to find vtk_backplot.py file in instalaltion but didnt find.

I'm fairly sure I fixed the 0.0035% bug I mentioned in the last post. Swapping two lines in the code should have been enough. Right now, I'm not aware of any real bugs in my firmware. I will continue using it with the dongle/pendant on the mill. But unless something comes up, I consider it good enough.

Unfortunately, I was mistaken about the bootloader version where the dongle firmware can more easily be read out. It is possible for versions before 2.40, but not with version 2.40 or 2.50. So right now there is no easy way to read out the whole firmware from the dongles.

Take care. Mine is an adaptation, the original is here github.com/dbraun1981/hal-cia402/tree/main