CLX UDT's and Arrays

I know you guys have got to be beat down over this issue. I apologize for causing further beatdown.

I have done a bit of research on the topic here on the forums. I know you cannot alias real world I/O to a UDT array and I think that would defeat the purpose of the array except in unique circumstances.

I have no problems with understanding what the UDT's are, I do have a problem understanding some of the mechanics of it though.

For example: I have 5 motors I want to program for. Me being lazy, I can just drop in a programmed SBR to handle all of this repetitive functionality. I guess my biggest issue is how do I actually get all the real world IO into the array and have it step through the iterations which are unique for each section that the motor controls?

Overloads, start PB, Stop PB, HMI Overrides are all individual animals dedicated for each motor so what is the mechanism that allows me to step through the 5 iterations using different real world IO? Rather how is that assigned in the Array?

It has been a long day and my mind is beat down, admittedly. I hope what I was trying to get across makes some sense.

I use UDT's with function blocks. The UDT make-up has generic tags that can be uses over and over. Then you plug the actual I/O into the function block.

When I come accross motor control programs written where there is one routine and the parameters are passed and returned I would gladly strangle the author. Do you know how hard it is to fault find when something goes wrong and how little extra time it takes to have a dedicated routine for each motor. Also have a look at the hit on scan time. We will never allow anyone at our place to program this way.

Regards Alan Case

Alan Case said:

When I come accross motor control programs written where there is one routine and the parameters are passed and returned I would gladly strangle the author. Do you know how hard it is to fault find when something goes wrong and how little extra time it takes to have a dedicated routine for each motor. Also have a look at the hit on scan time. We will never allow anyone at our place to program this way.

Regards Alan Case

Click to expand...

Here! Here! I agree!

bitmore

Alan Case said:

When I come accross motor control programs written where there is one routine and the parameters are passed and returned I would gladly strangle the author. Do you know how hard it is to fault find when something goes wrong and how little extra time it takes to have a dedicated routine for each motor. Also have a look at the hit on scan time. We will never allow anyone at our place to program this way.

Regards Alan Case

Click to expand...

I COMPLETELY agree. Why??? This is exactly what I am dealing with at the moment. The original integrator did exactly this. It has been a nightmare to track down the physical motor information since documentation is so slim. The maintenance techs are fairly lost in this since they don't understand how the physical input is not listed as the OTE.

I ask this specific question in how this is being accomplished so that I could look at it more specifically (being fairly new to CLX, not AB but certainly to CLX). I usually deal with Beckhoff products and almost exclusively ST but this is all done in LL with EVERY motor set in a array.

It does not take that long to fix the problem and if you are fairly good and know what you are doing it can be done on line while the process is running. (as long as a mistake will not cause huge damage, loss of profits etc)
You create a routine the same as the passed parameter subroutine but direct access everything for that particular motor.
Then put a rung with a JSR (with no parameters) below the rung with the JSR (with parameters). Make a new bit called test toggle and put an XIO in the top rung and an XIC in the bottom rung. When you are confident the programming is correct you toggle the bit. (if it fails just toggle it back.
When you are happy it is working then delete the JSR (with parameter rung) DO NOT delete the subroutine that that the JSR calls until all the referenced motors are altered.

Regards Alan Case

Alan Case said:

When I come accross motor control programs written where there is one routine and the parameters are passed and returned I would gladly strangle the author. Do you know how hard it is to fault find when something goes wrong and how little extra time it takes to have a dedicated routine for each motor. Also have a look at the hit on scan time. We will never allow anyone at our place to program this way.

Regards Alan Case

Click to expand...

I hope you don't include AOI's in that...
Parameterized subroutines, sure, but not AOI's. (At least AB AOI's, where you can see the particular instance logic)

A properly designed subroutine used as a function block, or an AOI, used for motor or valve handling should have all the fault-finding code incorporated into it, to inform the operator/maintenance guy what is wrong via alarms or status.

There is absolutely no need to go digging into the PLC if only one plant item is misbehaving, the problem will almost always be external to the PLC. The function-code should be able to work out what is wrong.

Now take the case that every valve or motor misbehaves in the same way, then the problem will be in the software, and should be easy enough to find and fix in one hit. But if the plant item handlers had been written as "standard" code, then this "fix" would have to be repeated for every handler.

I'd go with function code every time - and follow it up with ensuring the maintenance guys know exactly why, what the benefits are, and how they should respond to fault reports.

daba said:

There is absolutely no need to go digging into the PLC if only one plant item is misbehaving, the problem will almost always be external to the PLC. The function-code should be able to work out what is wrong.

Click to expand...

Well said.

A few years back I had a customer that had concluded that PLCs were complicated and unreliable. Every time he would walk by a machine that was down he would see a group of maintenance techs huddled around a laptop and came to the conclusion that the PLC was at fault and he needed more people who understood PLCs better. The problem was, he already had good PLC techs; His staff was short on people who understood mechanical and hydraulic systems. I said to the manager "I saw you have an ad in the paper for another PLC tech. I suggest you cancel it and hire a hydraulic tech because at the end of every wire is some kind of an actuator and your line has hundreds of actuators." He hired a guy who is really good with hydraulics and uses test gages instead of a laptop and hardly knows anything about PLCs but he can pinpoint the fault quickly and accurately.

A properly designed subroutine used as a function block, or an AOI, used for motor or valve handling should have all the fault-finding code incorporated into it, to inform the operator/maintenance guy what is wrong via alarms or status.

Click to expand...

I learned a lesson a few years ago. I use to get the machine running, and then planed to do the fault code.
Management saw the machine running they were happy and move me onto the next project. Fault code never got finished and I got phone calls all the time.
After that I made sure I did my fault code along with the machine code. Found my fault code was actually better and more complete that way. I actually install my fault scrolling code first.
Now with the use of UDT's, Function Blocks, AOI's. Fault code has to be done in this way.
No logic is complete without fault code.