1394, SLC 5/04, and PV 1000

Hey everybody,
Right now at school I'm working on a trainer with a 1394 GMC Turbo 2 Axis Drive System, connected to a SLC 5/04. The 1394 is connected to the backplane of the SLC. I also have a Panelview 1000 connected via DH+ to the SLC. The Panelview is working like it should with the SLC, but I can't get what I do on the oanelview to control anything on the GMC. I have already programmed a sequence in GMC Commander that I want to happen, and I have tested it with discrete inputs to a FlexI/O connected to the GMC. All I want the Panelvie and SLC to control right now is enable the servo drive to run, and completely stop the servo drive, keeping the feedback for both axis on. I need help really with how to address things in the SLC to address to the GMC, and also how to program in GMC Commander to add this feature. From what I tried, when I have what I thougt was teh correct addressing in the SLC, nothing on the GMC worked. When I removed the inputs from the SLC from the GMC program, it works fine. Can anyone give me any ideas.

BTW, the GMC is in the SLC on slot 7.

OOPS, that should be GML, not GMC...
Sorry, it was late at night when I posted this, and I was kinda tired and not actually sitting in front of the thing.

OK, well, I'm guessing either nobody knows anything about the kind of problem I am having trouble with, or nobody wants to help. The main issue I am having is that it seems like the SLC is not passing the bits that are turned on that care supposed to be correctly addressed to the GMC. I have created 2 input bits in GML Commander from the SLC, and sometimes they work, but most of the time they dont. Also, I don't think that the SLC is passing float values at all. If anyone has ANY kind of experience in working with these 2 please help.

The support on here for the GML drives is limited, mostly because they were junk and not many people are stuck with them anymore. This is not a slam to your school, because I know it's tough to get good equipment to train with, but the 1394 platform is a bad platform to teach on because of the drive's inconsistencies.

That being said, #1, is your GML program in run mode? If the GML program is not running, nothing will happen. When you are online with the 1394 drive, there is a small play button in the lower left hand corner. Make sure this is running. After that, more detail is needed about how you addressed your things, and comms between the drive and PLC.

Yea, the GML is DEFINITELY the hardest thing I've worked on so far. I am having some serious issues with the thing. I haven't had this much diffuculty on anything that I have worked on. OK, my setup is pretty simple, well, I think it is, and the way the AB manual describes how it all should work I understand, well, at least the theory I understand. I have a SLC 5/04 with a 7 slot rack. The GML is connected to the backplane bia the expansion port. I can get the GML program to work without the input from the SLC. There are 4 inputs connected to a FlexI/O that is connected to the GML. I have had no trouble with that at all. The SLC is configured with the GML in the 7th slot, which is the 1st slot of the 2nd rack. So, any addressing within the SLC to the GML should be addressed to O:7(insert various word/bit here). And from what I read, the first 8 bits of the first word are reserved. So, I am addressing the 2 bits that I am trying to pass to the GML as O:7.0/8 and O:7.0/9 . I have also defined 2 input bits within GML Commander withte addresses 0 and 1, respectively. I thoguht that these were correct since the first 8 bits from the SLC are reserved and are not user variables. I always have the program running, and on occasion the GML actually sees those bits in their correct states. Otherwise, it only reas them as off. I have tried forcing the bits from RSLogix500, forcing on O:7/8 and 9, and I have tried just using O:7/0 to see if it owuld read that, but it wont read it at all. I don't understand what I am doing wrong. In GML COmmander, I ahve it configured to work with a SLC, with Fast Data transfer, and set for 8 inout bits, and 3 floats. So yea, I have no idea what I am doing wrong here. Any ideas u have, please let me know...

Do you have the 3-inch thick book "GML Commander - reference manual" It should have come with the software.

It does a pretty good job of covering most situations.

I've worked with several 1394 GMC servo systems but they were all RIO, I've never used the SLC backplane connection before.

I have the same situation as 93lt1. I have seen several with RIO connections, a few standalone, and a few that were discretely controlled through the Flex, but never with the SLC option. I would need to see your file and possibly set it up on a trainer that I have access to.

Russrmartin, I guess I don't think of them as junk, just hard to use. Many people just don't understand how to program them properly. GML is not very descriptive unless you have the BIBLE(which I do not have myself right now, anybody know where I might be able to get one?). Heck, I was just called in to a local client to remove some Axi and change the program. Once we got past the wiring issues from the install, the program fired right off without any tweaking.

David

Well, I do have FlexIO on it as well, but Im not having any problems wiht that at all. It works beautifully, which is why I'm not understanding why it isn't working. I can try and send ya the files a bit later from RSLogix 500 and from GML Commander if you'd like to see the setup. I just don't understand, though, why it isn't seeming to interface properly.

I agree, It would help if you could post the RSL500 and GML files.

antjon1: Please post your files. I have used the 1394 Turbo w/ a SLC 5/04 and Panelview 1000. This was actually a 4 axis system (no coordinated motion though).

As I recall, there are some MSG instructions you may need to have in the SLC program to make the interface work. Once it is working, it is the greatest thing since sliced bread (althoug I think Control-logix has it beat now with it's integrated motion cards).

Right now I'm changeing a system over from the 1394 Turbo to a deviceNET servo drive and it is defineatly much more work to get all the information transfered between the PLC and Drive over Devicenet than it was with the 1394 Turbo.

I have attached the section of my file that did the handshaking for the M1 and M0 files. In my case, the 1394 was set up in the I/O configuration starting at slot 17. The m1 and m0 files were both configured for a length of 512 and the scanned input and output words were 32 each. I think if you don't need more than the standard 32 words of I/O provide you won't need the M file stuff but I'm not sure. I had a lot of float data to transfer. Remember that a flot takes up 2 words of data.

Also note that the first output bit for your slot (In my case it was O:17.0/0) must be on for the program to run in the 1394. The second bit (O:17.0/1 in my case) is used for stopping the program in the 1394. I can't remember if it had to stay on or just be on momentarily but I had it controlled by an internal bit that didn't have any output instruction written for it. The negative of that bit drove the Stop Program output. This let me toggle the bit online and start and stop the 1394 program. If I remember correctly, the 1394 didn't like you being online over the serial cable when the PLC was commanding it to run. Also, it seemed the best way to get things going after making a change in the 1394 was to hit the reset button and let it all start up by itself.
Whatever it was, the 1394 is now a dying platform. AB stopped making any upgrades to GML over 5 years ago and is throwing all it's eggs in the ControlLogix basket.

Hope some of this is helpful.

David,

I say junk because I think they were a poorly designed product. We have had issues with intemrittent fault problems, and axis running even after commanded to stop, drive program has been stopped, etc, not to mention how they are not receptive to power losses. That being said, I'll get off my soap box.

As NdZeid said, ours are programmed to start and stop the program from conditions in the PLC. I don't think that the Run needs to held on, as long as the PLC is not issuing a stop command. Regardless, I don't think that this is Antjon's issue.

Our system does not have any MSG's associated with it, but I'd have to look to make sure that we are using the same setup as you. We do have a word back to the PLC from the drive. Bit 0 is the drive running bit. Check this in RSLogix and make sure it is active when you are commanding the drive program to run. This is a foolproof way to check your communications. I can tell you that you are correct to begin with bit o:7/8. What is really puzzling is that you said GML intermittently sees the bits. Perhaps this has to do with the whole program running during serial communications problem.

Lastly, I do agree, the fat book is the bible.

Russ

Having an extensive fault routine was key to getting a system that would function in a production environment repeatable. I never had a run-away axis reported to me in about 5 years of the 1394 Running so far.

I have attached my main module as well as my fault routine module. The fault routine will restart the program over if there is anything except a runtime fault. As russ mentioned, the PLC can monitor the 1394 running status and, you'll also notice at the beginning of my main routine there is a block that waits for the SLC status to be running. This tries to guarantee that both things are runnign at the same time.

Also, just so I'm saying this more clearly than I did before; strange things can sometimes happen when you connect serially at the same time the 1394 is running and communicating with the SLC. I believe that serial communications are very low on the priority list and you can miss a lot of what is going on in full run mode.

One more hint. There is a checkbox under the Configure Control Options for run program on startup. If you don't do this, you always have to connect serially and start the program in the 1394 (even if the SLC tells it to run). This also lets the program come back up running when the fault routine resets the drive.

Hopefully most of this is right. It's been 4-5 years since I had to connect to the thing.

Excellent stuff Norm.

So few people realize that the secret to the 1394 is handling the faults and unknown conditions.

Russ, I understand your frustratin with them. I was handed the book, the unit, and expected to do. I had to learn, but I had some time to play, and I did. I created all sorts of different scenarios and taught myself most everything I need to know on them. IT was the fault routine that I had problems with. I finally called some Rockwell engineers and they instructed me on how to do it properly. I then created something along the lines of Norm's routine. Never have I had movement, a runaway axis, or any other undesired actions since I wrote that.

But it is a Dinasoar. And on its way out, but there are a few out there, so we need to remember.....


In reality, when my employer called me on this last one on Saturday, I grimaced...


David

I agree, we do need to remember, but the hope here is that these will be replaced with the Kinetics and not have to remember for much longer. We have a fault routine similar to what Ndzeid posted. Our problem was intermittent, maybe once every 3 months, sometimes longer, sometimes shorter. Basically, when we issued a stop command, and disable the axis, sometimes we get one that remains running. We have talked with AB people, and their consensus is that the problem is in the drive, and not one specifically as in one bad drive, but a batch of poorly designed drives. I'm not 100 percent, but it has something to do with once the axis is disabled, the drive will not process a stop command, so, if for some reason we issued a stop command, and then a start command again, then disabled the axis, it would produce motion. This was on a machine which works with rotary action, and was told to activate at a certain position. At certain machine speeds, when the machine would go down, 1 axis would continue to spin indefinitely. To me, an axis disabled should be the very last resort of a stop command. This is just one of the things I don't like about the design. This would be like an Estop being hit, and then if the start button was pressed before the ESR dropped out, machine could run. I personally think this type of thing should be avoided, and I think most people would too. It just happened that I think our friends at Rockwell, missed one. We've also had problems with power losses to the drives causing intermittent noise errors, or programs not starting, etc. Arrggghh, you got me going again. Just my personal preference.

Anywho, did Antjon get his setup working?

Sounds like your real problems aren't with the 1394 per se, but rather with the embedded S-Class motion controller and its GML programming.

I have worked with GML and have no praises to sing.
I have also programmed several CLX systems with 1394 servos attached - both analogue (1756-MO2AE) and Sercos (1756-MO8SE). They function very well.

the hope here is that these will be replaced with the Kinetics and not have to remember for much longer

Click to expand...

I'm sure AB would love to sell you all new drives (and motors?), but you can save yourself big bucks by just replacing the 1394 system units (sercos would be my choice).