Advanced Search

was this ever resolved? one of the youtubers I watch is currently having a similar problem with a different make of mill but with the same "following" error..

Ok, well that went over my head. Was so focused on the LWR issue.

You need to get rid of most of the "UNMATCHED" messages in the syslog.
"UNMATCHED " are usually caused by bad latency or very commonly by using RealTek network adapters.
If you have a Realtek network adapter, you should install the r8152-dkms or r8168-dkms driver via apt.

Can you show the output of "lspci -k"? Only the network interfaces are of interest.

+1 if you have good latency

Thanks everyone. 

Now I can make Yaskawa Sigma X  OP state and jog move from LinuxCNC stably.  ( Just did EoE disabled. )
Slave : SGDXS-xxxxA0x EtherCAT(CoE) SERVOPACK Rev02.09

According to the specification on Web, ( www.e-mechatronics.com/product/servo/sgm...c/xs_ether/spec.html)

LRD, LWR and LRW   seem to be supported. (attached image)
 
​​​But Sorry, I'm not familier with this problem.

Which configuration seems to be better in this situation?

refClockSyncCycles="-1" , with messages "Failed to get reference clock time: Input/output error"
refClockSyncCycles="1" no messages

Should I check some error from log? 



 

Thanks, Mark.

I did not include the pendant yet because I had to be aware of scope creep. I also didn't include things like coolant/Fogbuster valve control and a touch-off probe.

I'm not sure what the underlying issues were with the Indramat, but some of the symptoms were:

• One of the servomotors didn't run at all
• One of the servomotors did run, but stopped at random places
• The last servomotor sometimes just started to run, without giving it a command, and when I did give it a command it didn't run at all.
  
  After debugging for weeks I figured the "easy" way would be to just do a complete redisign. And boy, whas I wrong.

I've recently made a proper user panel on my lathe. But since I'm no
longer using the keyboard or the mouse the screensaver keeps blanking
the screen, so I have to press a key on the keyboard or move the mouse
to get the screen to wake up. I could of course completely disable the
screensaver, but I would prefer not to.

The buttons I use come from the usb through hal_input. The handwheels
are connected to the motor drives.

I cannot imagine I'm the first to encounter this issue, so has anyone
already solved this?                                                            

Somewhat of a novice here but like you it has been several years since my last retrofit/build of a LinuxCNC machine. The last machine built was back in 2020 and the pi platform was not really a good option then. Currently I just retrofitted a full size industrial CNC router and I am using the pi5 8GB with a Mesa 7i96s. So far it has been flawless and totally stable. My motivation for using the pi is basically downloading the image and go, other than a couple of minor tweaks to the OS (my preferences) it just runs out of the box. Using the pi I don't have to worry about finding another PC that would work in the event of a hardware failure and the fact that I can make multiple super cheap fully operating copies of the OS on a SD card cannot be beat. The machine that I just retrofitted is going to be used in a production environment and will need to be totally reliable day in and day out.

about the VFD, it depends on the type,
i have only a hy_vfd and no real examples, what kind of VFD you have ?
is it realy modbus conform or like the hy_vfd a modbus like protocol ?

The new PR is up, this fixes everything, i will post some pictures later
Edit:
Still got a few kinks to iron out, probably tomorrow for finalized PR

Maybe reset the encoder count on each index pulse? Then it would not count to such high numbers. But this will break the speed output of your ddt (I think). Does the EL5151 not have an encoder velocity output? I just used a similar Beckhoff part recently but can't remember, I don't think I used or needed velocity (speed) feedback in that project.

there are an buildin watchdog, it will disable the pwm/stepdir output if the connection is lost.
you can also set a chain of 'modifiers' to each pin (plugin -> Pins -> Modifiers) like delay, debounce, ... and 'onerror'.
The 'onerror' modifier hold the pin to low or high if connection is lost.

You can also use the 'chargepump' hal-component (www.linuxcnc.org/docs/html/man/man9/charge_pump.9.html) to control a master power relay.

Ok, so I think I understand what I should do. Using the StepperOnline Motion Studio software, I change the ENA polarity from high to low so no input is disabled and 5V input enables the motors. Additionally, I can switch the ALM polarity from low (default) to high and take that input in as inverse. Basically like a NC estop. For the wiring on the ENA, can I daisy chain them together? Also for the ALM, can I run those in series with the GND coming into the first driver and the last driver returning the GND back to the controller, with 24V as the input common?

yes this is a requirement now. nonstandard modules require a virtual environment (venv) in a folder. Google python venv

Pid maxoutput limits in the positive and negative direction. So, you can set maxoutput to 1.0 and it will limit the output in the range of 1.0 to -1.0

I'm not sure what it would take to prevent windup below 0.

For what its worth, one thing that has bit me in the past in trying to tune PID and lots of troubles with windup: slow vfd accel/decel. If the PID is tuned to respond faster than the ramp time of the VFD, that'll wind it up.

Also, a hal limit1 component might be in order to prevent sending a negative voltage to the vfd analog input, some kinds smoke when they get negative signals.