About bschmidt

bschmidt

Hello, On a synchronized motion application we want to delay the error reaction to an F2XXX error in the drive the so the axis can remain synchronized to the master. Then in the application code the master will be brought to standstill and the axes will be disabled. There is NC Reaction setting in the drive for this purpose: However the corresponding Axis in ctrlX Motion sees the error bit in the Drive Status Word and immediately stops the axis. How can we change the axis error reaction in ctrlX Motion to work in a better way with the drive setting? It seems like the answer should be in motion/axs/Drive1/cfg/dev-err-reaction, but I tried all the available settings and the axis is stopping immediately in all cases. The option ESTOP_PRESERVE seems like it might be the right setting, however when I try to apply this it goes back to the previous setting. Note: I use Easy Startup Mode in the drive, the drive is remaining enabled and following the internal command for 10s after the F2XXX. This is one way to verify that ctrlX Motion is shutting it down. Best regards, Brian

bschmidt · ‎08-07-2024

Hello, An application with 1.20 system apps has a network bridge setup so that the ctrlX CORE and an IPC connected to XF51 can both be reached with a single physical connection to XF10. Screenshots of this setup are shown below. In general this is working ok, but sometimes the communication stops working. It happened today such that neither the CORE or IPC would respond to a ping. The CORE web UI could still be reached via IPV6 and from there the CORE was rebooted. After reboot everything was working fine again. I have attached the system report/log files. Please let us know if there are any known issues or ideas to improve the robustness of this communication. Best regards, Brian

bschmidt · ‎07-23-2024

Hello, We have a customer with two different machines that have experienced the Sync manager watchdog error. On one of the machines it was happening at least once a day. Both were already using ctrlX CORE 2.6. About 1 month ago the C12's of both machines were upgraded from 1.0.1.45 to 1.0.1.51. It has improved the issue, but apparently not eliminated it completely. Both machines have experienced the fault since the C12 firmware upgrade, but much less frequent. Also both machines have these "unexpected/no response on cyclic Ethernet frame" messages in the ctrlX IO Engineering diagnostic log seen at the bottom of the screenshot below. These don't seem to cause a problem, but they might be related to the Sync manager watchdog error which eventually happens. One machine has 1.0.1.51/FPGA 219 and the other has 1.0.1.51/FPGA 221, so we don't think the FPGA version makes a difference. Are there any settings we should try to adjust? Are there more improvements expected in the firmware? Best regards, Brian

bschmidt · ‎06-27-2024

Hello Jochen, Great, thank you for the update. Regards, Brian

bschmidt · ‎06-26-2024

Hello, Following up on this post. Why does the axis have to be in Standstill for these FB's to Execute without error? This seems to be an unnecessary constraint which adversely affects the customer's working code from previous versions of ctrlX PLC (or MLC/IndraWorks). Could this please be changed to how it was working previously? Thanks, Brian

About bschmidt

Delayed axis error reaction

Intermittent communication loss with network bridge between XF10 and XF51

Re: [SAFEX-]C.12[/C.15] Sync Manager Watchdog

Re: MB_InitTouchProbe error in Motion 2.6

Re: MB_InitTouchProbe error in Motion 2.6