It is still a PC with PC electronics wrapped in an industrial package. There may be a few more industrial grade electronic parts, but it is still typical PC hardware.
The program we tested with is pure a test scenario, we do not have already the effective cam profiles.
The final machine will be a packaging machine.
I see. The cam profiles change because the parts are placed at different locations.
The test scenario is an acceleration part, constant velocity part, deceleration part and dwell part. The idea was to constantly attach another cam, because the MC_Camin instruction is usually one of the more load intensive instructions.
Yes, however I doubt all axes need to execute the MC_Camin in at once.
A lot depends on the implementation of the MC_Camin in.
As said, we observe jitter peaks between 200 and 300 µs.
Also the execution of the MC_Camin takes a peak of more then 500µs.
This is a Codesys runtime on Linux.
Is that for just one axis or ALL axes executing a MC_Camin instruction at once.
Attached is a trace of jitter and cycle time and a monitor of maximum and minimum jitter and cycle time (all in µs).
It would be good to have some values that would be reasonable for motion exection.
Again, there shouldn't be any jitter. Phase delay between inputs and outputs should be very small. The problem is that you should be using a Real Time Linux at least. The second problem is that PC or IPC don't have the necessary hardware.
My solution is this:
https://deltamotion.com/products/motion-controllers/rmc200
It uses a military grade RTOS by Green Hills so the RTOS is fast.
More importantly is how we do the I/O to make sure it is all synchronous and deterministic. There is a FPGA the does the inputs and outputs for all axes at the same time. There is no need for time stamps or the like since all the I/O is gathered at the same instant and at regular intervals. There are no delays due to interrupts being off or high priority tasks hogging the CPU. The FPGA is kind of like a PLC but instead of executing the rungs one after another and being delayed by overhead. ALL the rungs are executed at the same time.
Finally, there is software. Even 20 years ago we could move from one cam or what we call splines to another using a 80186.
https://deltamotion.com/peter/Videos/JAN-04 VSS_0001.mp4
There are 6 actuators and 3 top and 3 bottom and a photocell and scanner up stream out of view. The scanner scans the log and determines the best way to cut the log. It is not cut straight but rather the it follows the sweep of the log to get the most out of it. While one log is executing its cam/spline, the scanner/optimizer is downloading the next cam/spline so it is ready when the previous log is done. This was 20 years ago on a 16-bit integer only CPU. Today we have multicore CPU with 64bit floating point. Appending cams/splines seamlessly should be easy.
What I don't understand is that you mention constant velocity sections and acceleration sections. Wouldn't a normal move command handle that?
