Webbs

NC413 #8000 Double Command Error

11 posts in this topic

We currently have a C200HG-Z with a NC413 card. This machine operates 24/7. Axis X & Y control one side of the machine and Z & U the other. Around once or twice a month we get a #8000 error (Double Command Error) on the X or Z or both axis. After clearing this error the machine will run for 30 seconds and the error will occur again. The only way to properly clear it is to restart the PLC and it will work for another 2-3 weeks. The code for each axis operates via Step Step Next and only sends a move signal via one step then waits until the Position Complete flag before moving to the next step and giving another move command. After speaking to Omron NZ they suggested adding a not P_Step before sending the next move command but this hasn’t solved the problem. Can anyone help??

Share this post


Link to post
Share on other sites
Such an intermittent error is hard to debug even being this machine programmer on-site during the issue. The least you should do is to post the code and the memory image taken when the problem appears. Edited by Sergei Troizky

Share this post


Link to post
Share on other sites

Here is a copy of the code currently running. NC413_Mach_5_Setup is where the NC card is setup. Servo_Control_A_Side_Car (X axis) and Servo_Control_B_Side_Car (Z axis) are the 2 sections of code which generate the error . I currently don't have a copy of the PLC memory but will try and get one.L4C_Unloader_2008_07_24.cxp

Share this post


Link to post
Share on other sites
I really have no time for the program deep study, but see some questionable points. The error #8000 means more than one bit activated simultaneously in the axis control word (except the direction bit for jogging or interrupt feeding). 1. The step technique (by STEP/SNXT) used for sequencing in your program, allows the actions of two neighbor steps to be executed in the same scan. Hence, the program has to be verified for existance of neighbor steps that both contain activation of the same motion axis control bits. In cuch case measures must be taken to delay the actions of the later step by one scan. 2. I see at least one rung which is not guaranteed against activating two control bits at a time (see the attached image, the version on the right is how I would correct it). Analyze and correct the program for the described possibilities. If the issue remains, I would write a diagnostic latch for each axis, that will store the steps and control word image on the error appearance, for further analysis. Edited by Sergei Troizky

Share this post


Link to post
Share on other sites
Thanks for the quick reply. The rung you have highlighted is actioned only when there is already a fault and then as you pointed out could cause another fault i.e. the #8000 Error. It is something we can put in to stop the error occurring if there is a fault. The only 2 Steps I can see where 2 commands are close is Step 55.08 and 55.08 - rung 37 and 41 where it changes from absolute movement to jog. But there is an Axis not busy to move to the next step and a Not P_Step also an Axis not busy before the bit for the jog command is set.

Share this post


Link to post
Share on other sites
One more possible scenario: if a step with active coil is left while the coil is active, the bit will remain On until another instruction resets it. I would replace all 150.03 coils with SET 150.03 and add unconditional RSET 150.03 in the beginning of the scan. Edited by Sergei Troizky

Share this post


Link to post
Share on other sites
Initially you had DIFU and RSET at the end and now have changed to SET and RSET at the start. The not P_Step should stop the jog command starting before RSET resets the bit on the next cycle..... I will try it on Monday when I can watch the machine for the day to make sure it doesn’t cause any other issues. Thanks

Share this post


Link to post
Share on other sites
I realized that the reset in the end os the scan will never allow any actions by the bit, as it will be always off after the scan execution. This was the reason of my suggestion correction.

Share this post


Link to post
Share on other sites
Unloader_2008_11_13.cxpI finally managed to implement the changes you suggested. I upgraded from a C200H to a CS1 a few weeks ago and carried out the changes then. I kept all the same hardware (other than Controller Link card) and the system was working fine, but over the weekend I got the double command error again. After the PLC and Drives where reset it was all OK again, the same as with the C200H. I have attached the new CS1 version of the code (it also includes a SFC for another part of the machine). The calibration section is only carried out on the first scan or when the button is pushed and is not used during normal operation.

Share this post


Link to post
Share on other sites
Well, then I would replace all command bits with writing value into the entire control word. E.g. SET 150.13 or 150.13 coil to be replaced by MOV #2000 150. For proper operation of former coils, MOV #0 150 must be executed in the beginning of the program. Edited by Sergei Troizky

Share this post


Link to post
Share on other sites

I know this a really old post. However I recently experienced a similar issue using a STEP/SNXT routine to control a two axis NC213 motion card.

I have always used the P_Step flag A200.12 prior to every SNXT instruction to ensure that one PLC scan passes prior to transitioning to the next STEP.

I discovered that the transition to each step were so fast that occasionally i got the failed #8000 Double Command Error.

Sometimes this occurred on a daily basis and at other times once a week. This was driving me crazy!!

I discovered is that even though the motion flags [Move Absolute, Move Relative etc. etc.] are shown as rising edge commands in the NC Card manual, this is NOT the case, each motion flag needs to remain ON for some time AFTER THE BUSY FLAG TURNS "ON".

Therefore after each motion flag is turned ON in a STEP it transitions to the next STEP when the motion card BUSY flag turns ON, BUT ONLY AFTER A DELAY.

The STEP when the card is BUSY transitions to the next STEP when the motion card BUSY flag turns OFF, BUT AGAIN ONLY AFTER A DELAY.

The technique I implemented for the delay was a change of state in the word used for the STEP routine flags. This SET a delay flag that was used prior to every SNXT instruction.

The delay flag was reset after 3 program scans which allowed the SNXT instruction to transition to the next STEP.

It appears that either the NC documentation is incorrect OR the STEP/SNXT routine is so fast that it was causing the #8000 Error.

My 2 cents.

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now