Advanced Search

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

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.