Unican buffer observations/suggestions

[Ausman]

Hi all,

Something interesting and useful.

Would like some suggestions on an observation.

I have a V130 talking with a 120 via Unican, and over time with program improvements I have been adding more and more communicating of parameters both ways between the two via Unican sends.  I posted about this some time back and the answer was pretty much just send blocks concurrently as things will work.  This has all been working fine with my having a trigger for the operation in both units based on SB13 and 202.

I have always been a little frustrated by the lag in response of the 120 when accessing remotely through the 130 via the LAN.  Recently I was onsite which is imperative for an "iffy" change in such a crucial system, so I decided to change the trigger to SB15 (instead of 13) in both units.  There was a definite improvement in remote access timing, and all the information needed was still being transferred correctly.  Left 3 hours later all still working OK.

Next day logging in remotely I couldn't get into the 120 at all, not even to do an initialise and reset.  I ended up having to firstly change the 130 back to SB13 and then that let me get back into the 120 to also change it back, but with some timeout hiccouphs along the way.  A bit of nail biting as this was all being done remotely as the site is two hours away!

So....I obviously had some sort of buffer issue that gradually built up over time to eventually make the bandwidth needed for access via Unican unworkable, but there was still enough for the Send/Receive components to still be working fine.  I don't know whether the inter-unit accessing "linkage" is also controlled by the Unican parameters I have set for the send blocks.....someone know?

I have always thought my SB13 timer a clumsy method of control as the two PLCs might drift around to hitting it concurrently, but I have also been under the impression that although Unican didn't really mind this it still needed some sort of buffering.  My experience shows that some sort of buffer allowance is definitely needed, so I can't just use SB202 as the trigger.   It would seem that even if 202 says things are ok, there might be another few scans needed to really clear things.

So what is the best solution here? 

Is it to setup a count based system where the two units "ping-pong" off each other?  ie 130 does it's sends, and in doing that it sends one bit that is read and reset by the 120 which waits a few scans and then does the same thing back to the 130 ad nauseum etc etc?  The ideal number of scans would have to be ascertained by trial and error.  The problem I see with this is if something goes astray, because it relies on the link working perfectly each and every time, the entire link will fall over.  But I could cover this with a master "timeout" of say 10 seconds in each plc monitoring the bit changes.

Or use some of the SIs to better control things?

There is not a lot of help info about Unican capabilities, perhaps a bit more involved detail would be good.

cheers,

Aus

 

[Joe Tauser]

UniCAN is supposedly token based.  I don't even bother with timing - I just call SEND blocks and let the controller take care of it.

Can you post what you have for both programs with the proprietary stuff removed?

Of course you could just upgrade the V120 to a V130, too.

Joe T.

[Ausman]

Thanks Joe,

I essentially have things set up as the help files, with 3 Unican sends chained instead of the single element shown in the help .  I have attached scrnshots of a bit of my code that relates to this, and particular areas of the help file, notably the parts that stress not to directly do a send...use a trigger.  Ideally the triggers for my application are at most 1 second apart.  The one second trigger worked fine, lowering it to 100mS seemed to create the issue.  I have the sends in both the 130 and 120 set as low priority...haven't tried using high and it's associated SB.

The problem with the job is the remote nature of it, I can't experiment too much in case things go so far astray as to prevent access or correct operation.  Upgrading is not possible at present...the usual "we have no $s" that you and I have whinged about!

cheers,

Aus

[Joe Tauser]

100 ms may not be enough time for the token to go around.  I've had other experiences with Unitronics function blocks requiring a bit of "cool-down time".

Have you tried making your own request timer and varying the setpoint to see where it fails?

Joe T.

[Ausman]

Are you saying that it might not be the buffer, just a token clash due to a gradually coinciding trigger time? 

In that case I will definitely try the "ping-pong" system, which is in line with your request timer suggestion.  I would set it up to easily vary the number of scans before the trigger activates/resets things, to trial different delay times. The system is running 500Kb at 0.5 sec, which I might vary a bit just for interest's sake as well.

But it is curious that I am running controls that supposedly say everything is ok to do further operations,  which surely accounts for any sort of clash anyway.  I still had the Unican Sends in the ladder all working OK, just no remote access, so this pointed me to the buffer.

Due to the crucial nature, the distance away and strict "do not ever touch this" rules for staff on site, I will only do the changes when there.  I've been caught once and I don't like driving 4 hours for 2 minutes work to rectify something I created!  I'll set it up for my next visit and will advise results.

I repeat that the help file could have a bit more detail about various operations and real world limitations.

cheers,

Aus