Multi-Named Inputs

[robert.beal]

How do I create an input that needs multiple different descriptions. I have a robot tool changer that has 10 different tools with an I/O interface module. X50 means ten different things. Can I use a string SS/LS to populate the description field of X50?  The only thing I have come up with is taking x50>Out C0-C10. Name C0-10 with the proper descriptions then use those c-bits in my ladder logic to represent the X50 Status. I would have to do this with my Y-bits just everything in reverse But also dealing with outs,sets and resets. If the description wasn't limited to 132 characters would work too. Does anyone have any other ideas?

I am using Do-more Designer 2.7.4

Thanks!
Robert

[RBPLC]

I'm not sure I understand what you're trying to do. X50 on the BRX would be the same digital input regardless of what triggers it. It sounds like the tool changer could pick one of multiple tools but still trigger X50 on the BRX? How would you differentiation which tool was active/picked up or whatever you're trying to accomplish? Is there logic before X50 gets triggered?

[robert.beal]

Yes, there is logic in the tool holders. I know which tool is loaded on the end of the robot. Depending which tool gets loaded x50  means 10 different things. On the first tool it's (X50 = Vacuum Cylinder Extended), and on the second tool it's (X50 = Clamped Part). Each head has 10 sensors and and they all do different things and each head is different doing different operations. i'm trying to update the descriptions for each input/output based on the tool I have attached. To finish one program 3 different tool changes happen. Hopefully this makes more sense. It seams like any robot tool changer or quick change tooling would have this problem but I'm striking out finding any answers. Thanks

[franji1]

Don't over complicate this.  Just use different C bits for each "function".  Map the X50 into the specific C bit function based on this logic (it would not hurt to always map them every scan, since they're just inputs and your logic will already be blocking out the non-applicable C-bit logic functions).  You had the right idea initially.

Also use different C bits for outputs.  HOWEVER, only ONE function can actually update the specific Y Bit at the bottom of the PLC scan (do NOT write all the C bits back to the lone Y bit  )

[ATU]

You could use a  UDT and have all your inputs and outputs and other data associated with tool kept together in an array. The I/O mapping as Franji described might be a little more involved transferring the bits to the I/O , but the advantage is that you could index all parameters according to the tool number which would make the programming way easier.

[Controls Guy]

Exactly.  Create a translation layer so the tool changer can think like a tool changer and the PLC can think like a PLC.

[robert.beal]

I have been coding for several years now and understand manipulating c-bits to get what I want, but using a (UDT, Array, Translation Layer) is new to me. I'm not sure where to start with this idea. Is there any code examples that describe this method?  Question for Controls Guy - are you saying "exactly" to Franji1 or ATU? Since I am using stage programming with 40+ programs, my plan with the c-bits method would be creating code in $Main so I can use the conversion through out all my programs. The rest of the logic resides in the other programs. I'm always ready to learn something new. Thanks for all your help everyone!!

[franji1]

I was thinking more of 1 UDT per function that is custom to THAT function.  Create a heap-item for that function, then have your code blocks for that one function reference that specific function's heap-item.

To relate this to an actual (built-in) example, the HSIO module does multiple functions.  Some are input, some are output, some are both.

There is an Axis Struct with 4 heap-items  of that Axis Struct type (e.g. $Axis0, $Axis1, etc.).  Axis Struct contains members like .CurrentVelocity  .Direction et.al.

Then there's PWMOut Struct related to the Pulse Width Modulation Output functions.  There are up to 4 of those (you have to instantiate them individually).  That structure has members like .DutyCycle and .EnableOutput

So, what are your set of functions?  Is there a different set of I/O and internal states for each function?  Can you have multiple instances of a specific function across different I/O sets (similar to HSIO PWMOut and Axis structures can have up to 4 instances of each one)?

Not all code-blocks would reference all the different heap-items.  The ones related to "Function A" would use FuncAStruct and heap item FuncA (e.g. FuncA.Output and FuncA.Input - I have no idea what you would call your members).  The ones related to "Function B" would use FuncBStruct and heap-item FuncB (e.g. FuncB.Speed and FuncB.MotorOn, whatever).

Then at the $tTopOfScan, you would move X50 into the specific current selected function's heap-item.  This would be long, moving X50 into FuncA.Input, but only if FuncA is the current function.  Similarly, in $tBottomOfScan, you would move FuncA.Output into Y43 if FuncA is currently selected, but move FuncB.MotorOn into Y43 if FuncB is currently selected.

This is closer to Object Oriented programming where specific code-blocks are tightly coupled to a specific UDT/heap-item, and you do the "translation layer" in the $tTopOfScan and $tBottomOfScan system tasks.

[Controls Guy]

Question for Controls Guy - are you saying "exactly" to Franji1 or ATU?

Either?  Neither?  I'm not sure.   

What I'm actually saying 'exactly' to is the concept of creating a glue layer distinct from the logic and transparent enough that the logic areas in PLC and tool changer can forget its existence.   One example would be creating a UDT for a VFD that exactly maps all the comms registers for size and location and having a comm call that talks to the VFD in Modbus and then deposits the data in an instance of the UDT, complete with meaningful names.

You might create a UDT for each tool changer that maps the I/Os to meaningful names.   Then you have a program block that only executes the logic for the current tool changer, and you can do all the logic using the meaningful names in the UDT elements.  Then, you wire whichever UDT instance to the physical I/O depending upon which tool changer is in use.

[Controls Guy]

Another trick that might be worthwhile is some loopback pins in the main connector to the PLC so that the PLC automagically knows which tool changer is plugged in.   If the minimum changer ID is 1, so that a zero value indicates no changer plugged in or an error, then you can get up to 15 changers with 4 pins and 4 PLC inputs.

[robert.beal]

You guys are making me scratch my head, and I don't have that much hair left. . I'm going to try this idea and see if I'm picking up what your laying down. I will let you know how it goes. Thanks again for everything, you guys went above and beyond to help me figure out a solution.

[ATU]

Don't be intimidated by UDTs. They are a great tool and can make difficult applications simple and easier to document.  Create a UDT with individual bits or  one or multiple DINTs for your Inputs and Outputs, perhaps add DINTs to identify the Tool types, Real numbers for parameters such  as Max Cutting speed or other parameters. Then create a memory block array of this UDT, just like you would create an Array of Timers. The only thing you can't do (yet) is define an array or a string inside the UDT.  Then you can use the elements from that array in your program and only have to change the index to access the data for that tool. Play with it.  This is all done with the Memory Configuration dialog box.

[Controls Guy]

Then unions can be helpful here too.   UDT instances aren't as address- or type-agnostic as general table memory, so you can't MEMCOPY in and out of them to arbitrary positions.  However, since you can manually adjust the order and exact location of individual UDT elements, you can overlay them.  So if you have a bunch of bits at word 3 in the UDT, you could also define an INT  or DINT at that same location and use whichever type of address works well for a given operation, like copying in and out from I/O or HMI registers.

[Controls Guy]

Hmmm, you could even union yourself into having multiple usable names for the same location. Interesting.

[franji1]

Hmmm, you could even union yourself into having multiple usable names for the same location. Interesting.

Unions sound "cool", but trust me, unless you are an expert in the architecture of the union implementation at the hardware level, stay away from them if you can.  This is the purpose of the "abstraction layer", so you do NOT have to bring up the hardware level (e.g. X50) to the main control logic.  Call it what it IS based on the FUNCTION, not ALL THE POSSIBLE THINGS it can be ACROSS ALL FUNCTIONs.