Advanced Search

Am I right in thinking you have battery-buffered encoders?Then you don't need homing.First remove the loops and see if the errors decrease. Dmesg requires admin rights.

@Aciera you should come play with the primary vtk display for qtpyvcp!! looks like you have sorted a good bit out, would love to have it native without needing a secondary add-in for simulation.

@andrax
I will purchase CAT6 cables as short as possible to prevent any loops probably the next week. I do not think there should be any EMC since, as I mentioned earlier, the drives and motor are on my testbench. There is no high voltage machine around, just computers.  Still, I do not exclude that EMC is the actual problem. I attached pictures of the drive setup and the mini pc I use.
By the way, when I try the command “dmesg | grep ethercat”, I got an error: "dmesg: read kernel buffer failed: Operation not permitted". Only "sudo dmesg" works.
Another interesting fact that I observed is that when I type "ethercat pdos", there are a few rows where it show 0x0000:00, 0bit, 'Gap''. As if there are missing PDOs. I might be wrong but, should I somehow define in the servo drive what PDOs and SDOs to be mapped in the variable PDO and SDO mapping.

@3404gerber
The truth is that I compiled the cia402-homecomp from source a few days ago and the example is a much older.

@rodw
I checked the original version of the component and the example there has only one row for homing that receives the index pulse from the servo drive but still I could not execute a successful homing procedure with it as well.

correct, from within the opened running fully loaded qtdesigner you open your templates for editing.

I don;t know if you noticed but that procedure returns 1 when the machine s turned on so until it does that, you just wait... Then you do all the homing and other things

Hakan, as far as I can tell, the component should try to reconnect after a failed asyncSetupTransfer in case you comment out the assert call. It should then after a short while fail on libusb_control_transfer, which then calls setDoReconnect(true), which in turn should cause a restart of the USB stack.

If you run the component with the -a flag, the console output when it fails would be interesting to see.

Hi all

I was thinking to add a diode laser (10w 450nm style) to my cnc.
I have an EC500 box and the laser is driven with a 5v pwm signal.

How can I setup a PWM output. I did a lot of reading but didn't really find a good answer.
Which pins are capable of outputting a PWM signal.

If anyone has some example config they could share or if they could point me in the right direction I would appreciate it.

Thanks
Alex

once done you ONLY edit while running:

editvcp probe_basic

this goes for when you edit anything including the user sidebar, the user tabs, user buttons etc. this opens probe basic in qtdesigner and qtpyvcp so all of the existing custom widgets are available.

DO NOT EDIT THE PROBE BASIC SCREEN or it will break you apt update ability.

only run it to startup qtpyvcp with full functionality.

Just to verify...
-> edivcp probe basic
From there i open for example the main-template (attached photo) if i want to add buttons?

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