Variables and Signals between CXs

Information and discussion regarding the ACE PackXpert software

Variables and Signals between CXs

Postby tiziano.ferrini » Wed Nov 04, 2009 6:19 am

I'm currently working on a application with 3 couples CX controller-Quattro.
- These robots pick parts from indipendent camera belts and place them in a common belt with pockets.
- The place belt have not encoders and sensors,and move itself forward step by step one pocket every second: it stay stopped 0.8 secs, and employ 0.2 secs to forward a pocket.
- That belt comunicates with one CX only signal BELT ON MOVE (that means hold places).
- I'm currently using PackXpert 2.1.2.8, every robots have Part Targets as fixed position.
- The goal of the application is to have at the end of place belt exactly i.e. 5 parts in every pocket.

Actually, I created a FIFO array managed by one controller that keep track of how many parts every robot placed in pockets; it needs to be sure to not overflow a pocket and if an emergency stop occurs, system must continue from the last situation.

So, every robot before place parts have to be sure the place belt is stopped and the actual place pocket is not full. To do that, the 2 CX controllers that have not the place queue handler have to read internal variables and signals from the first CX controller, the current way is using rm.read.num and rm.read.write routines but them employ about 80 ms for every read/write operation and sometimes a syncro problem occurs.
Maybe I can connect the BELT ON MOVE signal to every controller to reduce read operations between controllers, but what do you suggest me to speed-up variable comunications between controllers? Have you a different idea to do this kind of application?

THANKS
tiziano.ferrini
 
Posts: 9
Joined: Fri Mar 27, 2009 1:53 pm

Re: Variables and Signals between CXs

Postby CyleN » Wed Nov 04, 2009 4:03 pm

A few thoughts:

1) In your setup, if you are having to call rm.write.num multiple times per index, you can use the rm.write.nums to write multiple variables with 1 call.

2) If you are relying on each separate controllers reading variables on the PC, you could change it so that the master controller writes to ACE variables that map to V+ variables on each controller.

3) You could always open your own network socket in your custom V+ code to have the controllers talk directly to each other, rather than going through the PC.

A question for you: How common is it that you need to map data between controllers like this? Is this something very common? What are the typical time constraints?
CyleN
 
Posts: 77
Joined: Fri Apr 18, 2008 6:27 am

Re: Variables and Signals between CXs

Postby tiziano.ferrini » Thu Nov 05, 2009 1:25 am

I think open my own network socket could be the better way for my application. Data mapping like this is not so common because typically every belt in the applications have an encoder and a sensor that trigger every pocket, so everything is handled by PackXpert and belt tracking can be implemented.
In my application every controller must be connected to the others faster than possible because in every Custom Place Routines, I implemented a polling loop that ask for a signal status coming from the master controller like this:

CALL rm.read.num("/variabili/segnalestop", "CurrentValue", 3, stop, status)

WHILE (stop == FALSE) DO
CALL rm.read.num("/variabili/segnalestop", "CurrentValue", 3, stop, status)
WAIT
END


where "/variabili/segnalestop" is a Controller Signal variable Object relative to the master controller.
tiziano.ferrini
 
Posts: 9
Joined: Fri Mar 27, 2009 1:53 pm

Re: Variables and Signals between CXs

Postby CyleN » Thu Nov 05, 2009 6:20 am

I see. One possible change would be:

a) Create a numeric signal variable for each non-master controller that maps to a soft signal on that controller.
b) Change the master controller so that when it needs to update the status of the signals, it can do them all at once using rm.write.nums.
c) The non-master controllers can then simply look at the status of the soft signal.

Of course, a custom socket would still be the fastest option because it would not go through the PC...
CyleN
 
Posts: 77
Joined: Fri Apr 18, 2008 6:27 am


Return to ACE PackXpert

Who is online

Users browsing this forum: No registered users and 1 guest