Strange behaviour - cycle time very long ^{CODESYS Forge talk (Thread)}
Strange behaviour - cycle time very long
Last updated: 2015-05-31

Codesys - Cycle Time and Jitter ^{CODESYS Forge talk (Thread)}
Codesys - Cycle Time and Jitter
Last updated: 2021-03-18

Alarm Manager missing single cycle alarms ^{CODESYS Forge talk (Thread)}
Alarm Manager missing single cycle alarms
Last updated: 2022-02-24

How can I put a delay in a st code with a for cycle? ^{CODESYS Forge talk (Thread)}
How can I put a delay in a st code with a for cycle?
Last updated: 2019-11-12

Post by davidbo on RPI can system operation like rm in a shell have an impact on a Task cycle time ^{CODESYS Forge talk (Post)}
3.5 18 SP2 I think the control is 4.2.0.0. I am not in the office before on Wednesday.
Last updated: 2024-09-23

Post by mubeta on Some 'pathetic' errors in SoftMotion program ^{CODESYS Forge talk (Post)}
Hello everyone, I have a very simple program for the process, but it's driving me crazy and I can't see the problems I'm left with: Short topological description: Dual Core Berghof controller with softmotion runtime version 3.5.19.30; Two axes with servodrive on canopen bus, clocked distributed from master; Ethercat I/O node; 2 ms ethercat task, 2 ms canopen bus cycle time; I/O objects of the canopen master and canopen drives connected to the ethercat task cycle; Problem 1: Two separate programs each manage their own axis and drive, with separate state machines. A first axis moves primarily in velocity, except having to position itself absolutely at a predetermined point at the end of the job; the second axis, on the other hand, is a paper unwinder that changes, for each job cycle, from actions in absolute, relative, and cam displacement with the master axis. Well, the state machine of both axes was written in such a way as to call running the useful FB and change it on state change in this way: CASE i_stateMachine OF 0: o_Power(Enable := TRUE, bRegulatorOn := FALSE, bDriveStart := FALSE, Axis := o_PaperUnwinderAxis); o_MoveAbs(Execute := FALSE, Axis := o_PaperUnwinderAxis); o_MoveRel(Execute := FALSE, Axis := o_PaperUnwinderAxis); o_CamSelect(Execute := FALSE, Master := o_MachineAxis, Slave := o_PaperUnwinderAxis, CamTable := cam_PaperUnwinder); o_CamIn(Execute := FALSE, Master := MachineEncoder, Slave := o_PaperUnwinderAxis); o_CamOut(Execute := FALSE, Slave := o_PaperUnwinderAxis); o_SetPosition(Execute := FALSE, Axis := o_PaperUnwinderAxis); IF ... THEN i_StateMachine := 10; END_IF; 10: o_Power( Enable := TRUE, bRegulatorOn := TRUE, bDriveStart := TRUE, Axis := o_PaperUnwinderAxis ); IF o_Power.Status THEN i_StateMachine := 20; END_IF; 20: (* Avanzamento carta *) o_MoveAbs( Execute := TRUE, Position := o_Somewhere, Velocity := 25.0, Acceleration := 3666.7, Deceleration := 3666.7, Jerk := 48000.0, Direction := MC_DIRECTION.positive, Axis := o_PaperUnwinderAxis ); IF o_MoveAbs.Done THEN o_MoveAbs(Execute := FALSE, Axis := o_PaperUnwinderAxis); i_StateMachine := 30; END_IF 30: d_HomingPosition := ...; o_SetPosition( Execute := TRUE, Position := d_HomingPosition, Mode := FALSE, Axis := o_PaperUnwinderAxis ); (* ... *) IF o_SetPosition.Done = TRUE THEN o_SetPosition(Execute := FALSE, Axis := o_PaperUnwinderAxis ); o_LogServer.Append(sMessage := '...', lscClass := LOGSERVER_CLASS.ALWAYS, sdt := o_CommonsMgrData.systime.sdtLocal); i_StateMachine := 40; END_IF; 50: ... The code above is a sketchy example of what I wanted to write. But it gives me a spot problem: in some, the state change results in a drive error, which is unrecoverable except with a reinitialization via SM3_ReinitDrive(). Things are improved a little if in the program I always run the call of all softmotion blocks in this way: o_Power(Axis := o_PaperUnwinderAxis); o_Jog(Axis := o_PaperUnwinderAxis); o_Halt(Axis := o_PaperUnwinderAxis); o_MoveAbs(Axis := o_PaperUnwinderAxis); o_MoveRel(Axis := o_PaperUnwinderAxis); o_CamIn(Master := MachineEncoder, Slave := o_PaperUnwinderAxis); o_CamOut(Slave := o_PaperUnwinderAxis); If I don't execute all the calls of all the motion FBs used, when exchanging machine state often (but not always), the axis goes into error with event id THE_FB_WASNT_CALL... Done a little diagnostics it seems that the FBs return the bDone, before they are completely terminated. I tried doing the machine state exchange not with the bDone bit of the FBs, but with the 'standstill' state of the axis. It didn't seem to change anything. Problem 2: During the use SM3_ReinitDrive() I get the erro in the log: "NetID 0: SDO read error for object 16#607C..." Assuming that the device involved it's one of the two servodrive, (no others device are present in the network), I don't found any object 0x607C in the 'possible object list in/out' of the two drive, and I don't understand where this object can be listed. So any ideas and suggestions regarding these two issues will be very, very welcome. If you need the source project, I am willing to send it.
Last updated: 2024-07-17

Post by ton on How to create a stopwatch? ^{CODESYS Forge talk (Post)}
If you use LTIME() you will be very accurate and be able to have a normal task cycle time.
Last updated: 2023-12-16

IEC SparkplugB for MQTT enabled devices V1.0.0.0 is here ^{CODESYS Forge talk (Thread)}
IEC SparkplugB for MQTT enabled devices V1.0.0.0 is here
Last updated: 2020-10-31

Problem mit Pi4, Runtime V3.5.15.0 mit I2C enabled ^{CODESYS Forge talk (Thread)}
Problem mit Pi4, Runtime V3.5.15.0 mit I2C enabled
Last updated: 2019-08-05

Yellow triangle and bus not running error in Modbsu TCP master and Slave. ^{CODESYS Forge talk (Thread)}
Yellow triangle and bus not running error in Modbsu TCP master and Slave.
Last updated: 2021-12-07

Yellow triangle and bus not running error in Modbsu TCP master and Slave. ^{CODESYS Forge talk (Thread)}
Yellow triangle and bus not running error in Modbsu TCP master and Slave.
Last updated: 2021-12-07

EtherCat and Onewire bus can not run in the same program ^{CODESYS Forge talk (Thread)}
EtherCat and Onewire bus can not run in the same program
Last updated: 2019-09-30

Bosch BME 280 bzw 688 Sensor per I2C Bus steuern und Daten in Codesys verarbeiten ^{CODESYS Forge talk (Thread)}
Bosch BME 280 bzw 688 Sensor per I2C Bus steuern und Daten in Codesys verarbeiten
Last updated: 2024-05-22

Bosch BME 280 bzw 688 Sensor per I2C Bus steuern und Daten in Codesys verarbeiten ^{CODESYS Forge talk (Thread)}
Bosch BME 280 bzw 688 Sensor per I2C Bus steuern und Daten in Codesys verarbeiten
Last updated: 2024-05-22

Post by tk096 on High Cycle Times for SoftMotion_PlanningTask when using AxisGroup ^{CODESYS Forge talk (Post)}
Hi, under this circumstances the performance of a Raspberry Pi 4 should be sufficient to run a Softmotion robotics application. A closer look at the project would be required. Maybe you could contact the codesys support? Usually it is recommended to run the planning task cyclically every 2ms with task priority of 0 on a dedicated core. In the task configuration you can have a look at the average and maximum execution time of the planning task. You could use the function block SMC_TuneCPKernel (https://content.helpme-codesys.com/en/libs/SM3_Robotics/Current/SM3_Robotics/POUs/AdministrativeConfiguration/Computation/SMC_TuneCPKernel.html) to define suitable values for the parameters 'fSyncBufferDuration' and 'fPlanningInterval'. However, as previously mentioned, the performance of a Raspberry Pi 4 with realtime patch should be sufficient. The 'fPlanningInterval' parameter specifies the maximum planning step width in seconds. The cycle time of the planning task should not permanently exceed this value. A higher value reduces the computational effort, but can lead to a violation or no full utilization of the set limit values for velocity, acceleration and jerk. From a starting value of 0.016 seconds, the value should be increased gradually until the performance is acceptable. The parameter 'fSyncBufferDuration' specifies the size (in seconds) of the buffer between the planning and fieldbus task. The cycle time of the planning task must not exceed this value at peak times (this will lead to the error SMC_CP_QUEUE_UNDERRUN). A higher value can compensate for peaks in the cycle time of the planning task. At the same time, however, this also increases the latency for executing interrupts and aborting movements.
Last updated: 2024-03-22

SPI Bus, Modus und Geschwindigkeit ändern ^{CODESYS Forge talk (Thread)}
SPI Bus, Modus und Geschwindigkeit ändern
Last updated: 2014-09-10

BeagleBone Black mit I²C-Bus ^{CODESYS Forge talk (Thread)}
BeagleBone Black mit I²C-Bus
Last updated: 2022-11-29

Wago 750-837 CAN Bus Communikation ^{CODESYS Forge talk (Thread)}
Wago 750-837 CAN Bus Communikation
Last updated: 2010-02-24

EtherCat "Bus läuft nicht" PFC200 ^{CODESYS Forge talk (Thread)}
EtherCat "Bus läuft nicht" PFC200
Last updated: 2017-11-24

CAN bus on CPX-CEC ^{CODESYS Forge talk (Thread)}
CAN bus on CPX-CEC
Last updated: 2019-06-23

Frequenzumrichter mit CAN Bus betreiben? ^{CODESYS Forge talk (Thread)}
Frequenzumrichter mit CAN Bus betreiben?
Last updated: 2010-03-02

ASI-Bus und Digitaler Ausgang ^{CODESYS Forge talk (Thread)}
ASI-Bus und Digitaler Ausgang
Last updated: 2006-12-05

Beschreiben von Can-Bus-Variablen ^{CODESYS Forge talk (Thread)}
Beschreiben von Can-Bus-Variablen
Last updated: 2008-04-25

Ansteuerung M-Bus Beckhoff KL6781 ^{CODESYS Forge talk (Thread)}
Ansteuerung M-Bus Beckhoff KL6781
Last updated: 2019-02-26

CAN BUS - EXTERNAL COMMUNICATION ^{CODESYS Forge talk (Thread)}
CAN BUS - EXTERNAL COMMUNICATION
Last updated: 2020-03-04

Sort by relevance or date