On the left side of the screenshot you can see my hardware. This product is a 6-axis stewart platform and consists entirely of B&R products, we do not use any 3rd party products. As for the problem I am experiencing, I can give a motion profile to the system in an axis I want from the user interface that belongs to us. For example, let’s imagine that I give a motion in Heave, that is, in the Z axis, there is no problem until here and the system performs the motion profile without any problems. However, after waiting for about 30-45 minutes, when I press the play button to give the same motion profile again, the system gives this error. I have to reset again and continue. However, there was no such problem in previous systems. Could it be a hardware related problem?
This can be a HW related problem yes. The enable signal connected to your drive system appears to be unstable. If this is due to wiring, an unstable 24V connection or a defective drive is difficult to say.
You can check for the status ReadyToPowerOn = TRUE in the Info structure of your MpAxisBasic FUB before powering the axis.
We are checking with the friend who made the connections and design of our panel, but we have not found anything yet. If there was a regular error, for example, if there was an error in the wiring, we would expect to encounter it constantly, but as we said, it happens randomly after a certain period of time. So do you have any idea about error 14710?
14710 normally means “process variable not found”.
Since it’s thrown by the mapp com component, I assume there’s an issue by accessing a variable that’s needed for the mapp backbone communication.
I can’t swear, but it could be a follow-up error to the warning some 100 milliseconds before, that sounds like some misconfiguration or so regarding the mapp alarm system.
Could a error here trigger other errors? So can 14710 trigger 6021 and 29203? Also, when we did a test by keeping time a little while ago, we kept 20 minutes every time we gave the system movement. Under 20 minutes, when we gave motion to the system again, there was no error. However, it gives an error when we give motion after a waiting time exceeding 20 minutes. Is there a control in controller, driver or power supply module about this time problem.
But no, I can’t imagine that this “14710” triggers “some minutes later” a problem with the hardware enable of the ACOPOS.
Also, as I know there’s no “system integrated 20 minutes timeout” or so - of course the motion system for example immediately reacts if the communication network is lost, but there should not be a difference if an axis is in motion or not for whatever timespan, the software always has to react in the same way.
Hello,
We changed the power modules we were using and also tested the 24V power supply but unfortunately the problem is still not solved. We are trying to find the problem but I think we will replace the drivers as a last resort.As I said in the previous project, we did not experience any problems, the only thing that changed between the two projects was that we switched from the 8lva13 engine to the 8lva23.However, I don’t understand whether it might be related to this or not. Could it be affecting the runtime or automation studio version we use?
if the motor would be the cause, I would have expected other error messages (like “temperature model”, “overcurrent”, or something like that).
If somewhere in the project would be a memory violation (overwriting of variables or memory by misleaded pointer or string / memory operations), of couse almost everythin could be possible - but that should had happen also before changing the motor.
Since I’m not experienced with motion, I’m really sorry but I have no more idea what happens. To check if it’s really a hardware topic, I only can recommend to do some tests with an “empty project” on the PLC: so only include the things that are absolutely neccessary to get an axis up and moving with mappCockpit - then, try to switch on the axis, move it, stop it, wait … if the same errors happen, I would say it’s definitely a hardware based issue.
Also possible for testing could be, to really use a 2.nd power supply exclusivly for the enable inputs of the inverter - if it works then, you really have spikes on your 24V supply on the hardware enable inputs.
Hello Alexander thanks for your help, I can not do tests without a embedded software or my program. Because I get this error all the time I use my play button for motion. I need to give movement to the motors for this error.
Unfortunately, we have not yet solved the problem, now we are making another one of the same product. The same B&R hardware is used in the same panel.By testing two different systems, we will understand whether the problem is hardware-related or software-related.
We have found out why the system has this error and I would like to share the reason with you. It was an error caused by the Acp10Man version we were using and after changing the version, recompiling the project and embedding it into the system, the problem was fixed.
