Advanced Search

If you get stuck, I am in Australia and have a 500W laser head I need to buy a BCL-AMP for.

Good so far.
lcec_configgen reads the info from the ELMO drives and formats it in a suitable way.
You can read out the info yourself with "ethercat -p 0 sdos", "ethercat -p 0 pdos" and "ethercat -p 0 -v slaves"

For the error you have, was kind of expected. No easy way I know off to know the halpin names of a built-in device like the basic_cia402.
But you can find out with this series of commands (linuxcnc not started)From that output you should be able to find something that resembles cia-statusword (index 0x6041). Do the same for the other missing variables.
So with that info, you replace lcec.0.0.cia-statusword with whatever the output above says for 0x6041.

One can also look up the index of interest, any places but here are two basic ones
doc-legacy.synapticon.com/software/44/ob...pdo/rxpdo/index.html
doc-legacy.synapticon.com/software/44/ob...pdo/txpdo/index.html
You will probably need that for the other halpins, I guess they will give the same type of error.

Ideally your g-code should be designed and generated in a fashion that the tool is actually capable of achieving the programed feed rates. It isn't really a good practice to program code to execute at say F200 but the moves will only allow F40 and then expect to rely on that F40 as your feed.

Right now since the machine is trying to cut at the higher feed in the slow sections but "can't". When you slow the machine with the feed override, the slow sections will not slow down until the feed override percentage lowers the programmed feed rate below the actual capabilities of the machines parameter settings for those sections of code. So if the programmed feed is F200 but the machine can only reach F40 in a section, you would not see a reduction in feed in the slow section until the feed override is set below 20%.

If you were to insert realistic feed rates for the "slow" sections of code. Then the feed override should give you the results you are wanting.

Other things to do to improve this would be to increase the machine's acceleration capabilities in order to reduce affect of slowdowns caused by short moves. Run the code using G64 mode with more optimal blending settings (larger P and or Q tolerances.). Improve G-code optimization by using curves instead of approximating them with short line segments, increasing code segment lengths and making segments more co-linear (less corners). Really any thing you can do to make so the machine moves at the actual programmed g-code feed rate rather than at the limits imposed by the configuration settings/physical limitations.

The new edits will allow shift once fully tested.

As for key binding, that is inside linuxcnc, there is a blurb on it in the docs I think, but don't recall where and not sure if it would be connected to PB or not. You would be on your own there