Advanced Search

Yes now I see it I made a mistake, my English is very poor and the automatic translator also does not quite convey the meaning of the sentence.
Thank you.
I have one more question in the case of the spindle speed slider I have strange values depending on the last selection in the MDI panel even though I have them defined ini.

Ich habe nun einen Ecoder mit 10000 Impulsen pro 90 Grad an die Achse angebaut. Dann habe ich die Achse versucht mit PID Regelung zum laufen zu bringen. Das Ergebnis ist enttäuschend. Ich bekomme die Achse nur ruhig ohne zittern wenn sie sich in Zeitlupe bewegt. Die Achse ist am Ende zwischen ca. -70 und -90 Grad und -20 und 0 Grad total unruhig. Einzig im Bereich zwischen -20 und -70 Grad ist sie halbwegs ruhig. Damit ist leider keine halbwegs vernünftige Bearbeitung möglich. Die Linear-Spindel wird ja durch 34er Stepper mit angebauten Encoder an einem HSS86 Treiber (Closed-Loop) angetrieben. Die B-Achse sieht man im ersten Beitrag hier im Thread.
Nun habe ich eine vielleicht dumme Frage:
Kann man die Achse in open Loop laufen lassen? Also nur gesteuert und nicht geregelt.
Vielleicht kann man ja mit dem Encodersignal irgendwie den Stepgenerator ansteuern?
Ich komme da leider nicht weiter. Hat jemand hier irgend einen Vorschlag?
fragt Peter


 

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.