CLX and the use of UDT

[Aeroman]

Hello All,

I apologize for asking this fairly easy question in the forums but I am at a bit of a impasse. I usually handle the HMI portion of the project with dabbling into Mitsu and Beckhoff. I have been trained by AB (years ago) on the PLC5 and SLC series of processors. The CLX is a radical change obviously and is now being pushed as the new use equipment except by those who like cheap such as Beckhoff. My partner who was the smart one had a heart attack and passed.

My question is about UDT and how to utizilize it to do repetitive tasks. I could write the logic simplistically and make a seperate file for Motor for example to handle all these repetitive motor tasks and HMI feedback. I need this to do two things, one, be efficient and two, readable by the field service techs assigned to this particular equipment. There are is no time sensitivity (read that as a high speed process).

I have created the UDT tags I would need to provide HMI feedback and control of my process. I also created another set of UDT tags for safety purposes. The creation of the HMI is the easy part. I will then create a VB.NET app for the techs to quickly jump into the OPC server for a quick set of items that were the historical problems created by the customer.

Now that I have the UDT tags done for each section, and I know the process control I need to put in place (sequence of operation), how exactly is this written in ladder logic? I cannot use ST unfortunately. The customer does not want any ST in the program though the system this one is replacing was ST with FBD. It just means I have a ton of math to put in via ladder logic. I am looking specifically for how the call to subroutine operates with regards to the input and return parameters. I have a mountain of CLX documentation I recently downloaded but it is like walking in quicksand. I have ordered the emulator software from AB so that I can fully test everything before actual install and check out. I just need to get my thinking straight on how the prameters are passed and written to memory and the operation will fall into place.


http://www.plctalk.net/qanda/showthread.php?t=42810

I found this post which seems to explain it well, yet there is obviously something I am missing as I am just not making the correlation in the process. Do I make the tags controller or program specific? Each parameter pass the data is written to memory then the next pass and so on? I ask because I have run into situations where data was being written then overwritten due to poor original integrator installation (was never noticed by the customer because the information was not necessary to operation but was more of a offloaded metric for quality of operation). I would prefer not to walk in those footsteps.

I haven't found any links that specifically cover this. I apologize if there is a better thread out there that explains this process.

Thanks!!!

Tom

 

[zankorel]

I very rarely use subroutines because it removes a layer of code that can be essential to using the PLC to troubleshoot operational problems.

If your client has stipulated LL, then i would surprised if they would be very keen to make extensive use of subroutines. It would be far better, from a maintainability point of view, to use the UDT's but make a routine for each individual one.

 

[daba]

Now that I have the UDT tags done for each section, and I know the process control I need to put in place (sequence of operation), how exactly is this written in ladder logic?

There are various techniques used for writing a "sequence of operation" in ladder logic.

A very basic form is to have a set of rungs, each rung testing the input conditions required to advance the "sequencer" to the next step, each "step" represented by a bit being on in a BOOL array.

Each of the BOOL step tags would stay latched once each step had been completed. You can use OTL, (in which case the sequencer would not be affected by a power-up or a mode-change), or use a "seal-in" branch, (the sequencer bits would be reset on a power-up or mode-change).

Physical outputs could be driven by a series combination of : XIC bit_xx (when to turn the output on), and XIO bit_yy (when to turn it off again).

The bit-sequencer described above is simple to code, but has several problems associated, such as the difficulty in making the sequence loop backwards, or jump forwards etc.


A slightly more complex solution which overcomes many of the disadvantages of the bit array sequencer, is the numerical step sequencer.

In this implementation, each step is represented as a unique step number in an integer tag.

The sequence part is easy - rungs would be constructed to test what step you are currently on, (an EQU instruction), what input conditions you are testing for on that step, and an output bit to advance the sequencer to the next step. The "stepping" control is usually (but not always) performed in a sequencer control subroutine, which can be written once and re-used for more than one sequence.

Output control can then simply performed using LIM instructions, eg. LIM 5 StepNum 10 would cause an output to be ON for steps 5 to 10. You can also initiate other sequences (subroutine sequences) from a main sequence.

The numerical sequencer is easier to maintain, modify, and understand for most people, and has the advantages of being able to perform looping or jumping as required. (eg. MOV a new step number to the step tag).


Lastly, A-B PLCs provide the SQO instruction, which is like cam-timer. each time the SQO instruction is triggered, it will automatically advance its internal POSition count, and then output a bit pattern from a stored array to wherever you want. This instruction is really only suitable where the sequence of operation will never change, as setting up the bit array is tedious, and subsequent modification is difficult to achieve. A good example of where they are used is traffic-light sequences.

I hope this has given you something to start with ....

 

[daba]

I am looking specifically for how the call to subroutine operates with regards to the input and return parameters.

The operation of the JSR is very straightforward - you simply include as many Input and Return parameters as you need. For Input parameters, your subroutine needs the SBR instruction as its first instruction on the first rung. The SBR must have the same number of parameters as the calling JSR, and the supplied parameters (tag values or literal data) are copied into the tags specified in the SBR. Make sure the respective tags in the JSR and SBR are the same data-types, as no conversion is performed.

The RET instruction in a subroutine works exactly the same, passing the return parameter tag values back into the tags specified in the JSR instruction. Often these are the same parameters as supplied to the SBR. If this is the case, then just remember that the subroutine is working with a copy of the tag, and therefore you must arrange your logic such that the original doesn't get changed while the copy is being manipulated.

I have ordered the emulator software from AB so that I can fully test everything before actual install and check out. I just need to get my thinking straight on how the prameters are passed and written to memory and the operation will fall into place.

A word of warning, the emulator software passes the parameters bottom to top (i.e. reverse order to the CLX controller) !!

 

[Aeroman]

Your supplied informatin is much appreciated. I was in the middle of typing another question when I guess everything clicked. I think I get it now. The task I am trying to deal with is repetitive communications out to a server. This is something I never had to deal with before. I usually wrote a application to jump into the PLC and grab the data in the register not the other way around.

Thank god for you info on the Emulator. It would have left me just wondering what the hell I was doing wrong the first time I saw the emulator act that way. Especially since I need communications to happen in a specific order.

I will learn more about CLX as this transition progresses. Again, I do appreciate your help in straightening me out.

Tom