Quote from CS-Lab Support on 7 March 2023, 13:26

Hello,

You must use the previous version of Mach4 4612.
Our developers are preparing an update, but it will take some time.

 

Regards,
Wojtek

Quote from rob on 12 March 2023, 23:27

Have you tried the latest Mach4 version ? 5036 works well here with a CSMIO-IP-M, no more pid errors.

Regards

Rob

Quote from CS-Lab Support on 13 March 2023, 09:57

I found out about version 5036 shortly before the weekend.
I'll deal with it as soon as I can.

This topic, of course, is independently tracked by our software developers.

I can only say whether the issues encountered in the 5000 version were solved.

Regards,

Wojtek

Quote from TanTanCNC on 13 March 2023, 16:48

i did install version 5036 as well, same results: or system error or pid faults.

Quote from CS-Lab Support on 14 March 2023, 10:50

Same results? Thanks for the info. 

 

Wojtek

Quote from TanTanCNC on 14 March 2023, 17:57

see pictures for fault messages

M4 .5036 version

Quote from CS-Lab Support on 15 March 2023, 14:57

Hello,

During what activity do these errors show up?

I would like to add that the error "PID Fault mkit: 1 error 251" means that "Motor" number 1 in simple terms wanted to make an uncontrolled movement of 251 step/dir pulses.

To understand this, I need to explain something first.

Each of our controllers has one PID position loop for each axis (Motor or MotionKit).

PID loops are used to convert the trajectory of movement into step/dir pulses (CSMIO/IP-M and CSMIO/IP-S) or +/-10V (CSMIO/IP-A).

The trajectory provided by the control software (Mach3, Mach4 and simCNC) is the set position and the step/dir pulse counter (CSMIO/IP-M and CSMIO/IP-S) or the encoder pulse counter (CSMIO/IP-A) is the actual position.

Both values go to the PID loop, which results in the step/dir signal frequency (CSMIO/IP-M and CSMIO/IP-S) or the +/-10V voltage value (CSMIO/IP-A).

In order to monitor the effects of the PID loop, a security is used that constantly compares the value of the set and actual position.

This protection describes a very simple mathematical condition:

 

Setpoint – actual position <= following position error.

 

If the set position minus the actual position is greater than the following position error, the machine is immediately stopped in an emergency, and the message "PID Fault" appears.

The "PID Fault" message contains information about which "Motor" or "MotionKit" the problem is affected (e.g., "mkit: 1") and what position error value we are dealing with (e.g., "error 251")

 

In the case of the CSMMIO/IP-A controller, the user can set the value of the following position error because this value depends on:

- Correct position regulator tuning in CSMIO/IP-A

- Correct tuning of the velocity and current PID regulator in a servo drive.

- Servo drive condition

- Axis inertia

- The desired value of acceleration and axis jerk.

 

For CSMIO/IP-M and CSMIO/IP-S controllers, the maximum following position error is permanently set to 200 pulses.

This value is set rigidly because it does not depend on variable factors.

 

As I have already mentioned, the described security "constantly compares the value of the set and actual positions.

At this point, you may have a question, why should these values be constantly compared?

It is obvious that in the case of the CSMIO/IP-A controller, this should be done to control the correct operation of servo drives, but is there any other reason?

Well, there are three serious reasons:

- Mistake in control software calculations (Mach3, Mach4, and simCNC)

In this situation, the CSMIO/IP motion controller receives an incorrect trajectory (i.e., a set position), which is a command for uncontrolled movement of an axis that may lead to a collision.

- No synchronization between the control software (Mach3, Mach4, and simCNC) and the CSMIO/IP controller.

The CSMIO/IP motion controller continuously transmits the actual axis position to the control software (Mach3, Mach4 and simCNC).

This position is used to synchronize the control software with the motion controller.

Lack of synchronization causes the control software to generate a false trajectory that could lead to a collision.

- Lack of feature support or faulty operation of a feature on the side of the control software or motion controller.

Threat identical to the above points.

 

Quote from TanTanCNC on 17 March 2023, 18:29

thank you for this very good reply. i think i understand what you mean, but i did some more investigations. M4 .5036 seems to work with CSMIO/IP-S, i could let a program run without a fault. but..... when i use my pendant (pokeys or XHC) these PID faults come up. the fault does not seem to come when i use my keyboard to jog the axis. so from a cslabs point of view you could say "don't use these pendants". i use them for years now in combination with cslabs, no problem at all.

i did another test with the M4.5036 and the CSMIO/IP-S with probing. then this PID fault comes up, and that has nothing to do with a pendant.:

and of course the M4. 4612 version did not have these problems at all with the same hardware (csmio and pokeys pendant), M3 neither.

Quote from CS-Lab Support on 20 March 2023, 10:20

>> i did another test with the M4.5036 and the CSMIO/IP-S with probing. then this PID fault comes up, and that has nothing to do with a pendant.:

The situation is the same with the Mach4 5000.
This means that Mach4 5036 has the same changes as Mach4 5000.
Our developers will soon (in a week or two) release plugin 3.500, which will fix this problem.

>> when i use my pendant (pokeys or XHC) these PID faults come up.

It seems to me that we will not be able to help you with this problem as it seems to be beyond our capabilities.
MPG support (pokeys or XHC type) is handled exclusively by Mach4 (the only exception is hardware support for the CSMIO-MPG module,
which we added to get high-quality MPG work and make it easier for customers to configure).
This means that Mach4 deals with all matters related to MPG and sends to the controller the trajectory of movement to be performed.
The task of the CSMIO/IP controller in this situation is to obey the trajectory as long as it is not defective (too aggressive or rapid movement of the axis exceeding its capabilities).
If I were you, I'd check if you didn't make a mistake during the MPG configuration in Mach4, and in this way, you force the axes to do something impossible for them.