Modbus Wha?

[tmoulder]

Vision 280, Visilogic 8.6.3, serial modbus with Trio 206x

When I use NO and NC contacts on the RHR and PHR commands, it works. No errors in the status operand.

When I use P and N transisiton bits, it doesn't. All error 5.

I don't get it. At a ladder scan rate of 5mS, with a square wave being produced by SB7, logically, the one that works must be repeatedly sending 10 RHR and 10 PHR per seconds, pretty much non-stop.

But if I use a pulse, to give a nice leisurely 50mS for the Trio to respond to each command, it reports that communication cannot be established.

Whadaheck is going on?

TM

[Emil]

Hi Tim,

Sorry, but the way you perform commands - in both cases is wrong!

You must use N.O. contact of Function in progress MB as condition to start communication.

In VisiLogic, Help menu > Examples > V860 > Project examples > Communication > Modbus folder there are few working examples. You can take the example V120 - Modbus Master. Take a look on nets 3 & 4. You can exchange SB52 in net 3 with, let's say SB15 (positive transition contact of SB7).

Please check this way and let me know the results!

[tmoulder]

I looked at the examples and tried one such approach.

Making sure I had Function in Progress off, I triggered a positive pulse on my RHR command. And still got a 5 in the status, and the In progress bit came on and stayed on.

Does the command need to be maintained for a certain length of time to finish processing? It seems to behave that way, although I haven't tried a timer yet to check.

Thanks,

TM

[Damian]

I use this structure for all my modbus comm routines (RTU or TCP) and have never had issues

Looks like I will have to continue the rest in another reply. 500k limit

[Damian]

or maybe not ........... looks as though I have uploaded my quota for today

[Damian]

Cara, thanks for the tip!

and the rest...............

This will give you close to max comm speed as it relies purely on handshaking and does not utilize timers.

[tmoulder]

Hi Damian,

Thanks for the tips. My example was to illustrate that the PHR and RHR blocks do not seem to operate correctly when triggered by a pulse. I've got more work to do in that regard.

I noticed something interesting in your example - I've used a token scheme and used the Function in Progress bit to increment the token (I do use it, just not in the same net). I noticed you are actually using the message status, and I think I like that approach better. I'm going to take a stab at implementing it and see what I come up with.

By the way, kudos on using integer sequencing. Why can't everybody do that? ::sigh::

Hi Emil,

A couple of fast questions:

1. When a modbus FB like PHR and RHR is triggered, does the Function in Progress bit go high immediately (as the FB is scanned) or not until the Config FB is scanned again?

2. Does the PHR and RHR need to be scanned a certain minimum length of time to complete processing? From Damian's example, it doesn't appear to be so, but my tests seem to indicate otherwise. Official confirmation?

Thanks,

TM

[Damian]

Hi Tim,

A curiosity with the first PIC you have on your post. You are using the N/C of SB7 on your RHR function. I would expect the N/C of a pulse to literally be on for most of the 100ms and pulse off for a very short amount of time (say 2.5ms). Or more clearly, it seems your are sending your RHR and your PHR almost simultaneoulsy.

Emil .... Cara ....... It would be nice if the software gurus put some sort of graphic indicator on the function blocks themselves that tip you off if the function is of the type that should only be initiated with a transition. Maybe like a little pulse mark on the input. Would save a lot of confusion, especially for new users.

D

DOH!!! sorry .... I got SB7 confused with SB15

Edited November 12, 2010 by Damian

[Ash Neilson]

Tim - Are you using Modbus IP or just standard Modbus over RS232 / RS485?

I have found with Standard Modbus Installations, that the best way to maximize communication throughput without collision issues and what not is to use step logic (Usually sequencing on an MI).

Listed below is an example of the steps involved in this Logic:

1) PHR Block is called and we instantly Jump to Step 2

2) Wait for the Function in Progress Bit to be Off "0" before we Jump to Step 3

3) RHR Block is called and we instantly Jump to Step 4

4) Wait for the Function in Progress Bit to be Off "0" before we Jump back to Step 1

As shown above, you will be Sending out the Modbus Request, waiting for the Reply and then be ready to send out another Modbus Request.

One issue I have noticed with cheap RS485 devices is they have issues with me sending out a message instantly after I have received a reply - In that case you just add say a 20 - 50ms Timer before each Modbus FB is called

If you want I can send an example of this Modbus Logic in a PLC Program. I have used this logic for years on many installations and never had one issue.

[tmoulder]

Hi Ash,

>>Tim - Are you using Modbus IP or just standard Modbus over RS232 / RS485?<<

Serial, RS232.

>>I have found with Standard Modbus Installations, that the best way to maximize communication throughput without collision issues and what not is to use step logic (Usually sequencing on an MI).<<

Yep, I generally use a tokenized scheme, where each transition of Function in Progress from On (busy) to Off (Idle) increments the token and triggers a new transmission.

>>Listed below is an example of the steps involved in this Logic:

1) PHR Block is called and we instantly Jump to Step 2

2) Wait for the Function in Progress Bit to be Off "0" before we Jump to Step 3

3) RHR Block is called and we instantly Jump to Step 4

4) Wait for the Function in Progress Bit to be Off "0" before we Jump back to Step 1<<

I ran an experiment yesterday to illustrate what I've discovered and kicked it over to support for review. Essentially my finding was this:

When sending a transmission over modbus serial (PHR or RHR, it doesn't matter), the sending command must be held energized until the transmission completes. If you de-energize it prior to completion, the Function in Progress bit comes on and remains on - permanently.

Now, I always thought the FiP operand was governed either by the operating system (reset when the transmission was finished) or updated when the Modbus Config block was scanned. The test I ran indicates that it's being controlled by the transmission block itself, and if it stops operating, it never finishes updating.

My situation in this is a bit unusual. I'm revisiting an old project, updated to 8.6.3, and discovered this when trying to make the old modbus system more efficient. I may still be making a mistake someplace in the ladder, and if so, I hope support can point it out to me. But right now, I'm really thinking this is an OS issue.

>>If you want I can send an example of this Modbus Logic in a PLC Program. I have used this logic for years on many installations and never had one issue.<<

Thanks, I'd like to see that. I'd want to put it into my existing program and see if it operates properly. I did try an integer state approach (2=send, 3=wait for FiP to reset) and it locked up. My theory is that whether triggered by pulse or by change of state, when the transmission FB is no longer scanned, FiP is no longer updated. In which case, this method will not work either.

Thanks,

TM

[tmoulder]

I should clarify, this is a vision 280 with OS # 5.04 (B18)

[tmoulder]

Hi Damian,

I believe the pulse timers like SB3 and SB7 are square waves, on for one period, off for the same amount. Not sure if SB7 is on for 50 mS /50 mS or 100/100. I used to know this, but I turn 40 in a week, and my mind is not as clear as it used to be

Personally, I'd like to see a bit on the transmission blocks indicating function complete, rather than a single Function in Progress bit for the entire comm system. Then we could trigger changes for a block executing, instead of the entire comm line stopping.

Thanks,

TM

[Ash Neilson]

Hi Tim,

As far as I can see, "Calling" or "Activating" any Modbus Function Blocks using ONE pulse should be just fine.

I'd bet that calling another Modbus Function Block while a "Function is in Progress" could cause issues, hence the reason why Unitronics would recommend we make use of that "Function in Progress" Bit.

I have attached a VisiLogic Project I just created for you that makes use of a Vision 280 PLC. I tested using a Vision 280 running OS 5.04 Build 18 (The Latest) and found everything to be working just fine.

You will want to adjust the Start Address and Read / Write Length of all the PHR and RHR Function Blocks to suit any Modbus Devices you have.

I included an extra bit of Ladder Logic that I use to "Roughly" calculate how long each Modbus Function Block takes to execute.

Hope you can resolve your issues using this

Modbus Example.vlp

[Ash Neilson]

Thought I would also just mention

Tim - you are correct about SB3 and SB7. They are on for half of the Time Period then off for the other Half.

SB3 will turn On when the Second Value changes, then turn off 500ms later.

SB7 will turn On when the Millisecond Value reaches a 100msec Value (e.g. 100ms, 200ms, 300ms, 400ms) and turn Off 50ms later (e.g. 150ms, 250ms, 350ms, 450ms).

[Joe Tauser]

You guys are so proving my point...

Confusion in making something as standard as Modbus work is one of my biggest pet peeves.

Joe T.

[Damian]

I believe the pulse timers like SB3 and SB7 are square waves, on for one period, off for the same amount. Not sure if SB7 is on for 50 mS /50 mS or 100/100. I used to know this, but I turn 40 in a week, and my mind is not as clear as it used to be

Hi Tim,

Sorry, I was going from memory and confused SB7 with SB15. Realized it as soon as I hit send.

One thing I have noticed in the past. The very first time you initiate a Modbus function it seems to take appreciably longer for it to process than normal. After the first process, it then seems to be consistent. I wonder if your first call of the RHR or PHR is taking over 100ms and stuffing everything up thereafter.

[tmoulder]

Hi Ash,

Thanks for the program, I analyzed it this morning and tried it out, and it did indeed work. So I set about trying to duplicate the problems I was seeing.

First, I made a couple of modifications to the original, since I'm only using Unit 2. This worked fine as well (0 Original)

Second, I made a copy and blew away everything pertaining to Units 3 and 4 (1 ID2 Only), just to make it more clear for myself.

Third, I converted the bit-based token scheme you used into an integer based one (the way I normally do things) to see if the integers could be the source of the problem. The program worked normally that way as well. (2 Int Token)

Fourth, I went back to the bit-based program and replaced the NC contacts on Function in Progress (MB10) with negative-transition bits to see if that would replicate the problem. While I did have to toggle MB10 manually in online mode to kick-start the sequence, after that, it ran fine. (3 Pulse)

At this point, my theory got flushed down the toilet, but that's cool - I want to figure out where I'm going wrong. The thing that's confusing me is I tried both of these latter methods with no effect previously, so now I'm doubly curious.

One thing I did observe is that you use a NC bit on SB2 to ensure the configuration scan is done before launching transmissions. I thought the issue might be there, so I created still another routine based in 2 Int Token, and set it to scan immediately at powerup instead of waiting (4 Imm On). Still the program runs perfectly.

I noticed I'd left the PHR vector length at 2 instead of 25, so I changed it in 4 Imm On, and still it ran fine.

Dude! This is a fine piece of code. I wish american cars were this well constructed, I might buy one again!

Unfortunately, it still doesn't answer why my attempts in my own program, several of which were the same as these, didn't pan out. I'm now going to install this on my own program and see how it works.

Thanks for the help! I've attached the program with the revs for your perusal.

TM

Modbus Example Rev 1.vlp

[tmoulder]

So I put the integer tokenized scheme back into my program and it failed magnificently. Great...

So I began looking at differences between the modbus schemes. I noticed that your program used MB10 as function in progress, I was using 2041. So I replaced it with MB7. No change.

Also noticed MB10 had no power-up status, mine was reset. Cleared that, no change.

Added the NC SB2 to condition the IO Handler subroutine call. No change.

Eh, I'm going to lunch.

TM

[tmoulder]

I finally found the culprit.

Scan_Ex

I removed it from my program and it started working properly.

I added it to Ash's program and Scan_Ex killed it.

Checked the help file, nothing there about this sort of behavior, so perhaps the gurus in Support can chime in on it.

Thanks,

TM

[Ash Neilson]

Tim,

Sounds like your really having fun with Modbus!

Ah I see why you were having issues!

You can't have a SCAN or SCAN_EX Function Block being called while for example a PHR or RHR Function Block is being called.

As far as I know, you could stop SCAN / SCAN_EX, do your PHR and RHR Function Blocks wait for the Replies to come back, then run SCAN / SCAN_EX again.

I believe SCAN and SCAN_EX cause all the replies from PHR and RHR Function Blocks to be read and processed before they get back to their PHR and RHR Function Blocks. Maybe it even prevents the messages from going out in the first place.

Hope that helps

[tmoulder]

In gratitude for everyone's assistance on this problem, I wanted to share with you the program structure I was originally trying to achieve throughout this whole misadventure. You may have already been doing this, but if not, you may find it useful.

My current application is a V280 communicating to the Trio motion controller. The 280 issues command codes and target values to the Trio, which does all the grunt work. The 280 also polls the Trio for current positions and IO data.

In this application, the V280 doesn't need to talk that much, comparatively. It gives a homing command, the Trio executes, and the 280 watches the reply line to see the command is complete (for example).

Ash's very nice program demonstrated what I already knew from previous research, an RHR cycle took about 60 mS, and a PHR cycle took the same, for a total latency of 120 mS (approx). This was very inefficient, since 99% of the writes were transmitting the same data, and ate bandwidth I would rather have spent getting real data back from the Trio.

So I applied a little CanOpen technique to the PHR, and made it change-of-state. If the values to be sent are changed, the polling of the Trio data is interrupted, and when the Function in PRogress goes idle, the values are sent. Full latency of a complete RW cycle is still 120 mS, but the latency when not writing is only 60 mS, so I get much faster updates to the data coming out of the Trio.

Thanks again guys!

TM

Modbus Example Rev 2.vlp