I/O Unit state

David L

Hi <?: prefix = o ns = "urn:schemas-microsoft-com:office:office" />

 

I have created a graphical view of some slaves in a flexpendant appl. I want to show the current state of each slave in this window, but I can?_Tt figure out how to read the state of the units.

 

So my question is:

 

Is there's a way to read the state of an I/O unit (Running,Deactivated,Stoped)?

charon

Hi David,

I dont know if RAB have built-in function for monitoring I/O device status but i think u can do it like that :

If your robot have "multitasking" option you can use "IOUnitState" instruction in a semistatic task.

PERS num nUnit1State;
PERS num nUnit2State;

         WHILE TRUE DO
                 nUnit1State:=IOUnitState ("UNIT1");
                 nUnit2State:=IOUnitState ("UNIT2");
                 WaitTime 0.3;
         ENDWHILE

According to manual "IOUnitState" instruction have return values between 1 to 4
(1=unit running, 2=runtime error, 3= disable, 4=other cfg. error)

By using this numeric values with "data binding" you can observe situation of cards with RAB.



charon2009-12-08 14:05:01

Niklas Skoglund

FlexPendant SDK does not a have an API for working with units and buses.

 

For anyone interested in doing it with PC SDK you can dolike this:

[CODE]
Controller c = new Controller(...);
Unit unit = c.IOSystem.GetUnit("MyUnit");
unit.StateChanged += new EventHandler<UnitStateChangedEventArgs>(unit_StateChanged);
void unit_StateChanged(object sender, UnitStateChangedEventArgs e)
{
 IOUnitPhysState state = e.NewUnitState.PhysicalState;
 /// Do stuff with the state information...

}

[/CODE]

 

Unfortunately the e.NewUnitState.PhysicalState returns a type that belongs to an internal namespace. So you must add

using ABB.Robotics.Internal;

 

Formally that means that this code is not supported as internal types can change without notice between releases of the API.

 

The fact that the type is located in the internal namespace is most likely a a bug and and will be corrected.

 

Try at your own risk until then.

Niklas Skoglund2010-01-14 10:51:56