UniCAN Send Status

[Annatooli]

In Examples there is UniCAN example "UniCAN for CanBus between masters" and it does work.

But there is MI 0 what stores  UniCAN Send Status, problem happens when it turns 1 "network is busy". After that, no communication. Only way to restore communication is PLC OFF and ON cycle.

I wonder maybe there is some little less destructive way to understand when communications can be restored ? Maybe use some SB's or SI's ? 

[Ausman]

Annatooli, have you tried putting a "cyclical" call (eg below)  on the UniCan actions?  Or raise/lower the bitrate?  I have found it is easy to overload the buffers and you need to reduce the demand on the comms loop.  You can often set up a flipflop sort of thing on the various calls around the loop, allowing a few scans before proceeding to the next one.  The trouble with this method is if one receive/send falls over you have to program in a timeout "over-ride" progression.

In theory all of this isn't needed, but I have found it's the only way I can get it to work sometimes...depends on load. I've mentioned elsewhere on the forum how I have decreased interval times to the bare minimum that appeared to be working ok, only to find it falling over later, most likely due to a buffer issue.  A tiny increase in timings and the problem was fixed.

cheers, Aus

[Annatooli]

Your example is almost exact copy from example provided by Unitronics. except MI 2040 is MI 0 there.

Usually what happens is user turns off one of PLCs and after that all system has to be turned off and on again. It wont happen often, maybe 2-3 times a year, but all pointing finger to me. So I have to find solution.

Like you understand if MI 2040 turns 1 - no communication, after that point. I can change MI 2040 back to 0 and all wakes up, but maybe It can  by done using some SI's or SB's.

Anatoly

[Annatooli]

Basically there are big barrels with knives, during maintenance some of these knives needs to be replaced and for safety they switch off  entire cabinet. So people can go in.

Anatoly

[Ausman]

13 hours ago, Annatooli said:

turns off one of PLCs

Perhaps this is the issue.  Maybe you need to be able to manually select (under a "maintenance password") particular controllers in the loop.  Take it out of the loop for the shutdown, then put it back in after powerup?  Having never done this, I don't know whether this is possible the way UniCan works.  I'll ponder on this and let you know, unless someone else who may have done it OK chimes in....please.

The SB13 in the example is just that, an example, I often do it with counters incrementing each scan that let various calls be fine tuned much more precisely.  Mostly my scan times are consistent.  If not, I use the 2.5/1.25ms interrupt.

cheers, Aus

[Joe Tauser]

Take a look at the programs I uploaded in this post-

It's not exactly what you're doing but an EX-RC1 is indeed a UniCan Master when it sends data back to the PLC.  You'll see that I don't bother with the MI 2040 = 0 block; I find SB 202 is good enough.  I checked the Help under UniCAN system operands and you may want to throw a NC of SB 201 in there as well.

I've never had CANbus clog up, but I'm generally using less than five nodes.  If the Master sends a message and the intended recipient doesn't receive it, then the Master moves on.  This is why I have the nodes throwing messages back forth - I use the Message Arrived and Check Alive blocks as a handshaking mechanism.  It will reset itself when the other nodes come back online.

Joe T.

[Ausman]

13 hours ago, Joe Tauser said:

nodes throwing messages back forth

Thanks Joe, I have tried this in the past and couldn't get it to be reliable.  However, I am also using quite a few structs in series that might be upsetting transfer speeds, as some of the numbers involved vary significantly. 

The other thing is that I may have made a boo boo somewhere in previous attempts, so I'll try it all again some time and see how it goes, as I would prefer your method.  Do you put in some extra scans after the blocks change state, or just react to them immediately?  All my hiccouphs still say buffer over-run to me.

cheers, Aus

[Joe Tauser]

I don't run it that fast on an actual application.

The Unitronics examples are written to immediately react to a change and light the CANbus up with data in that scan.  NOW!!!  And again.  And again.  

So you could get CANbus requests every scan, and there's nothing in the ladder editor to call multiple CANbus requests in the same scan. 

This should work perfectly all the time.  In a perfectly built network, it probably would, but who really uses the specified trunk and tap cable?  The Creators will be quick to chime in - "Joe - you must use proper cable if all is going to work right."  And they are correct in this.  The reality is the users will often use cable they think meets the spec, which may or may not create an impedance mismatch and depending on the length and baud rate induce errors in the data.

Serial communication is hard sometimes.  Ethernet is easier, but that's another conversation.

There have been other posts with CANbus and Modbus TCP where response time is "Oh, My God So Important".   If you really do need hyper-fast communication then you should not be using a remote I/O system.  Period.

So I typically ping my CANbus at 0.1 second intervals and totally don't use that "data changed" method. 

Discuss.

 

Joe T. 

 

[Ausman]

My reply could be read as "speed is of the essence'', but it's not true.  What I want to do is run UniCan as it appears in it's description, and have it totally reliable.  I can only get this to work by having calls being made at a given periodic speed.  There is a fine time interval that the joined systems will tolerate.  Cabling is spec and only quite short runs less than 2m.

My eagerness to do it like you say is to have it done "properly".  It has always seemed a bit odd that having a request sent periodically via the ladder always has the potential for a conflict with another request somewhere else on the loop.  Especially doing it with a "defined" time interval.  It is unlikely, but entirely possible, that calls from different plcs could coincide exactly, and do so for some time if based on something like SB 13 or 15.

I think at the moment that I'd love the Creators to chime in and explain exactly how it all works, how the loop reacts to different plc calls etc.  Help gives information, but I think it could go into a lot more depth, covering things like Structs etc.  The "mechanics"of how it all works ok, including any time allowances for the amount of data zinging around, would be nice to know. 

It is only logical, Captain, that more data means more time needed! 

 @Saragani    @AlexUT    @Cara Bereck Levy  ? 

cheers, Aus

[Annatooli]

Check Alive, of course. How I didn't think of it 

Thanks for examples,  But I notice one odd thing  on the  EX-RCs you compare MI2040==1.  Isn't it  you wait  for sending until network is busy ?

Anatoly

[Joe Tauser]

30 minutes ago, Annatooli said:

But I notice one odd thing  on the  EX-RCs you compare MI2040==1

Good catch.  My only excuse is I was editing Paul's programs and re-posting them, and he was just starting from the example.  I didn't delete the compare block.  These days I don't use the CANbus status register in my logic - it is more of an informational tool.  Like this error counter:

I've found UniCAN to be extremely reliable if you don't overthink it.

 

 

 

Joe T.

[Joe Tauser]

3 hours ago, Ausman said:

It is unlikely, but entirely possible, that calls from different plcs could coincide exactly,

UniCAN is a token passing network.  This doesn't happen.

Joe T.

[Ausman]

Thanks Joe, I didn't know it was token.

I think I've always been literally going on this illustration:

My brain always puzzled on this along the lines of  "how do all the networked recipients do this at the same time without conflicts?"

Makes much more sense now.  And yes, I'm a dumbo for not picking it in the first place.

cheers, Aus

[Cara Bereck Levy]

Hi guys--I'm really late in replying here, sorry.

Yes--UniCAN is indeed token run, and UniCAN is, if you use the proper cable as Joe observed, about as stable as it get...

On 7/7/2020 at 1:27 AM, Ausman said:

I think at the moment that I'd love the Creators to chime in and explain exactly how it all works, how the loop reacts to different plc calls etc.  Help gives information, but I think it could go into a lot more depth, covering things like Structs etc.  The "mechanics"of how it all works ok, including any time allowances for the amount of data zinging around, would be nice to know. 

Is this the question? Specifically the 'call loop' in UniCAN?

[Ausman]

Cara, knowing it is a token loop explains a lot. 

The entire topic of UniCan and best practices has lots of info in Help, but for the learner it's a bit hard to tie it all together. 

I use Structs to assemble/disassemble the vectors for UniCan sends and have them in series, which is not covered as being possible.  Same for the UniCan Sends.   The help files imply that you can only do 16 integers in a single send, and that's true...but you can  do lots of sends in one rung.

I wrote about this here:  http://forum.unitronics.com/topic/4084-unican-sends-512-mis-per-scanhow/?hl=unican

The other thing that is not well explained and actually needs more work on it in Visilogic is the source/destination naming issue in Structs.  Unless you keep careful track of this via something like Excel, it gets very confusing.  I touched on this here:

http://forum.unitronics.com/topic/6527-with-vectors-why-didnt-i-think-of-this-ages-ago/

For me I also seem to have buffer issues that the system doesn't seem to allow for.  "Everything is done" says the system.....but unless you allow a few more scans for the buffers to fully clear you'll run into overload problems.  I am going to try again on some layouts...as discussed above.

To me the issue is that it needs some example layouts in the help files that show the entire principle for all types of different operations.  The sample projects show the basics, but don't show how much you can enlarge on what is being shown.  I know this is a learning curve, but I don't like stumbling along in the dark finding things out by trial and error.  I well remember spending days banging away on this when I first started doing it, having to do lots of testbench trials.  And you have to work with at least 2 plcs to do it properly, which adds to the annoyance as you have the 2 lots of download each time you try something.

cheers, Aus