Advanced Search

Really nice work thank you.

I’ve modified the interface so that the scanned surface can be visualized with a button press. The next step is to make the probing settings persistent across LinuxCNC sessions. These settings are stored in the .var file, but I’m not sure how to load them at startup and update the Qt widgets accordingly.

 

jjdege wrote:

Hi,
try changing the value in the .hal file

setp cia402.0.pos-scale 1000

 
[code]Hi. Pardon for offtop. Please could you try to explain what will do linunxCNC when you using this scale, and reach the calculating maximum of +2^31, and momentary jump to -2^31. On my case system stops and there an error of following..

[/code]

Hi
I doing retrofit on machine, used etheecat delta.
i used in hal file scale parameter pos-scale to adjust lenght of movenent

today i catch an error, when linuxcnc receive value during moving equals +2^31 and became -2^31, system catch that prevous value pos of axis calculated in mm was 380mm, and after count +2^31 overflow became -67mm. So there an error.

I have no ideas, and stucked) How to solve this trouble?
thanks in advance!

Most probably they will not work, inductive proximity sensors react to metal by inducing a magnetic field, but do give it a try, they might react, and might be polarity sensitive....

gtk-builder-error-quark: gvcp-panel.ui:72:38 Invalid property: HAL_Table.n_rows (11)
Warning: Forward kinematics must handle duplicate coordinate letters:yy
Embeded tab command "halcmd loadusr -Wn gladevcp gladevcp -c gladevcp -H gvcp_call_list.hal -x 58720684 gvcp-panel.ui" exited with error: 1
Shutting down and cleaning up LinuxCNC...

Different OS?

JT

Hello and Merry Christmas to you all,

I have written a ethercat driver for the EL2564 (led driver) - since there isnt't one yet - and tested it so far. Everything can be found in the attached ZIP archive. A video shows how it works

Have fun with it and enjoy tinkering in your workshop,
Pierre 


 

So, there is a much bigger issue with lcec supporting LWR and Yaskawa drives requiring LRD/LRW.

I followed some of your links and while there is some success, there are also very pessimistic opinions
on rewriting of lcec_main. Maybe it is possible to take some of the success and shoehorn it into something?

For Yaskawa Sigma7 the issue with lcec (linuxcnc-ethercat) software component is not only EOE being enabled in the drive.

It also has something to do with modes LRD/LWR and LRW. In the sigma7, the PDOs in the syncMasters are not read-write, i.e., LRW mode is not supported by sigma7. To work with sigma7, you need to enable 2 domains in the lcec program. I am not sure how to do that yet.

This issue is documented in these forum threads:
forum.linuxcnc.org/ethercat/50245-yasikawa-sigma7-lcec-driver
forum.linuxcnc.org/ethercat/48110-etherc...-responding?start=40

I have tried using this program from github.com/nylon7 and fdarling (on the yaskawa thread in the linuxcnc forum) and have seen some success in enabling the sigma7 motor and moving it and reading the absolute position register over ethercat.

github.com/nylon7/Igh-Ethercat-master/bl...ples/user/main_yas.c

For doing this, I am using the IGH Ethercat master 1.6-stable with EOE disabled as documented by Hakan.

I think we need to make some changes in lcec to enable the use of two domains.

-automata

I have used your syncToRefClock "true" option, the random jitter issue persisted. The issue is not just sync, it is also phase, by simply drifting to match the DC epoch, you can get in phase. Only after the fix I am NOW finally able to create the jitter at WILL by setting a sync0shift of 10~30us this is expected, as preempt_rt has 20-60us jitter, if you move the sync0shift window in the jitter you should get jitter, this was not the case with just syncToRefClock "true" the servo was in sync, but the phasing was random. I will further test tomorrow, but this is something that has escaped the community for a while.
Sync is also important, but phasing was completely overlooked, I think the current code assumes phase alignment happens automatically, this might be because of ethercat's docs not explaining this well, or because of how linuxcnc is structured the servo thread is started completely separate from the lcec, the servo thread phasing has to be done manually to match DC epoch, even if DC epoch was written by lcec, the moment when servo-thread addf's lcec is practically random, the phasing will be random. Not sure if you understand, I am very deep into testing this for days now, and I can assure you, I have it fixed now, but it was not before.

It can be that linuxcnc-ethercat disturbs the process. It must be removed too.
I think this way is the best after all. The other way with changing a bit in the eeprom is even more complicated with ned tools.

I went through the disabling of EoE on a development system I have. Here is the list of commandsAt this point you should be able to start linuxcnc.
Check syslog for EoE appearances.
Take it step by step.
 

Thank you so much.
I tried multiple times, but I get the same result.

I installed ethercat-master using "linuxcnc-ethercat" package (that include some packages ) . and that may caused some issue for replacing ethercat master.

Do I need to install some packages separately, step by step ?
Unfortunatelly, I'm not familier to do this and I could not find proper procedures so far.

Do you know some web links or somethings to instruct this procedures to do this?

Indeed, it is the servoloop that isn't in sync with the dc clock.

github.com/linuxcnc-ethercat/linuxcnc-et...s.md#master-settings

If you have been using linuxcnc ethercat, you almost certainly have experienced jitter, the motor makes a weird noise, restarting lxcnc once or twice, and it works well, no amount of latency improvements ever fix this completly, just happens a bit less often.
Since I had sometime to kill this Christmas I put a lot of effort into pin pointing the cause of this issue, and fix it for good, I will share the code in the next few days, still doing some testing and refinements, but I wanted to share what I am at this time practically certain the cause was/is.
The issue is the servo thread syncs with the DC clock, but it is not in phase, each time linuxcnc starts the app-phase is randomly out of phase with the DC epoch time (Fixes value of "DC reference time" displayed by ethercat master), the fix was to remove app-phase from DC epoch, and drift the servo-thread to align with this time, that's all, this will make sure your packets are sent (with jitter) in phase with the DC epoch, and your sync0shift will actually allow for your jitter/latency.
I will do some more testing refine the code, and soon share the fix with the linuxcnc community,
Merry Christmas and Happy Holidays to all!

tommylight wrote:

use short cables

 
 

Just noticed this. It is the answer. I think.

Move VFD much closer to motor. Shorter cable from vfd to motor.
That by itself probably fix everything without doing anything else.

Also keep all DC wires far away from AC wires.

In terms of interference, the wires going from vfd to the motor are the baddest. The longer the badder. To a lesser degree all the AC wires are bad when so close to BOB and all. Contactors are also very bad the instant they open/close.

BOB too close to relay and power wires.