Sanity Checking for Industry 4.0 Problem, Multtasking, WorldZones, Anybus etc.

MikeEd

We have project that is effectively an Industry 4.0 problem in that the process is very long (hours), highly dynamic and readjusts itself on the fly. We’re looking at some high and low level sanity checking because without it we have no realistic chance of ever commissioning without it – i.e we know what happened straight away, stop and track the issue, vs. finding a mess in data a few hours after the system gets lost.

 

Ideally we want to stay with the same architecture, IRC5 Controller communicate to a master PLC (L3 Compactlogix) using the EIP Anybus adapter.

 

Is there anyway to split up the “packet” from an EIP anybus adapter?

• i.e We want two groups; 
•           A fast dataset for real-time IO signals back and forward from the PLC (4-6 bytes) - 1-5 ms latency
•           The data/process handling information – in the order of 128-256 bytes (The max per the anybus card) - 50-200 ms latency is fine
• We could use Etherent/TCP for the data but that is very nasty on the PLC side

Can I get joint location  in a background task(Similar to RRI) and put that into the Anybus registers? (Only 5-20 Hz Update Rate)

• I don’t want all that code in the main motion tasks, but running in the background
• In my head I think we want a slow running task in the back ground that picks up the joint info and puts in the anybus regs- The problem being CRobT/CJoints is that is won't be in the correct motion task.
• Again, RRI uses Etherent/TCP which is awkward to handle in PLCs.

WorldZone Limits

• Is there a maximum number of worldzones that can be used in a system? And is there anyway of rotating these around the vertical axes so they’re not fixed in collinear to the world coordinate system? (I don’t believe there is according to the documentation)

Best Regards,

Michael

soup

1. I/O: Have you seen published latency numbers? -- I only recall seeing overall speed in Mbits/s.
   
2. Joint Locations: CRobT and CJointT both have optional arguments for choosing the motion task.
   
3. World Zones: The limit used to be 10, then 20, could be more now. Need more than 20?
   

MikeEd

My understanding is cycle time is the consequence of the Mb/s.  The higher the register load, the less cycles per second, and the longer the cycle latency.  Single ended IO, we’re looking at the order 70 Bytes of channels, then another 130 Bytes of group/analogue communication (So about 1600 bits total from a max of 2040).  The EIP network also has machine vision, IPC processing, SQL server so very busy.  An advantage we have is most of the group/analogue IO could comfortably be on latency of 100-200 ms, the single ended stuff ideally would be in the range 1-5ms. If I can split them anybus up, it should help a lot.

 

Thanks for that on the TRob, I did find not long after that is isn’t classed a motion command and can be used in other tasks.

For WorldZones, we do have over 100 discrete locations in a tight workcell, and a number of other zones we need to avoid robot collisions.  I never found a statement in any of the documentation, but I did some testing last week.  The limit is 20 per robot, not controller it seems, which is a bit nicer.  This gives us enough (just) for collision avoidance in production mode and that was the absolute minimum I needed to extract from worldzones.  I’ll need to do another background task (using TRob/TJoints etc) for the high latency PLC tracking, and I’ll need to come up with some funky startup routine for recovering from faults but it all looks possible.