[Modbus Wha?]

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

[Modbus Wha?]

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

[Modbus Wha?]

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

[Modbus Wha?]

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

[Modbus Wha?]

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

[Modbus Wha?]

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

[Modbus Wha?]

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

[Modbus Wha?]

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

[Modbus Wha?]

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

[Modbus Wha?]

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

[Interrupting the interrupt]

Greetings!

I'm planning to use the 1.25mS interrupt and the HSC with Reload interupt in the same program. My question is this:

If the 1.25mS interrupt routine is in progress, and my HSC reaches target value during this interlude, what happens? Will the timed interrupt be interrupted?

Thanks,

TM

["Formula" intermediate calculation]

I'm not sure I understand what you mean by "intermediate"? The formula block follows standard algebraic order of operations, so anything in () is processed first.

Are you actually using [] instead of () in your formula? I didn't think you could do that. If so, try using () and see if it corrects.

Thanks,

TM

[HSC Interrupt not triggering]

Okay, I got it.

To get the target position interrupt to work, you must use reload, and also set the Reload Enable bit. Which sucks, because I don't actually want the traveled distance to go back to 0. It would be better if the routine ran whether Reload Enable was set or not.

[HSC Interrupt not triggering]

I think I may have stumbled onto something here.

If the HSC Reload cannot be used with Shaft Encoder mode (because I1 would be the reset, and in shaft encoder, it's the B channel) then it seems that the target parameter is being ignored.

Yes, No, Maybe?

TM

[HSC Interrupt not triggering]

Hi Emil,

Thanks for the tip, but unfortunately, it made no difference, the routine is still not being scanned.

Reading the help, it makes repeated references to HSC with Reload. I saw from one of your posts in the old forum that HSC Reload won't work with a Shaft Encoder setup.

I'm pretty much out of ideas here, so let's review the basics:

1. Name the interrupt file properly

2. Configure the High Speed Counter in Hardware setup by selecting the counting operand and target operand (ML0 and ML1, respectively).

3. And that's pretty much it, right?

Thanks,

TM

[HSC Interrupt not triggering]

Hi!

I'm using a V350 with a HSC configured as Shaft Encoder x4. I have a preset and the encoder portion is working fine. The system is set up to turn on a feeder motor, and once the preset is reached, trigger _Interrupt HSC 0,1 to turn off the motor, via immediate out.

Problem is, the interrupt routine never runs. I've checked my spelling on the routine name about 12 times (seriously, need to use something a little simpler, like assigning a routine in the configuration). I put in a bit set command to trap if the routine ran, and it never came on.

I must be missing something subtle here. I'm using Visilogic 8.6.2, with the latest OS.

Thanks,

TM

[New feature for List of Text Variable]

On that subject, haven't seen any new intermediates in quite a while. Is the update cycle moving that fast, or has the location changed?

TM

[New feature for List of Text Variable]

Thanks Cara, that's great news!

TM

[Windows Live Gadget?]

I like it! Need a Google gadget too (Micro$oft is evil)

[Changing Key Labels on V350]

Thanks! That's what I needed to know.

TM

[Changing Key Labels on V350]

I've got a vision 350 I want to change the key labels on. I downloaded the data sheet on this, and it seems there should be a tab to grip to pull out the old F1-F2 label strip and insert my own. The only problem is - there's no tab.

Am I supposed to be able to insert my strip in front of the existing one (it seems like it doesn't want to slide up in there), or is the tab trapped inside the housing somewhere?

Thanks,

TM

[Operand window off-screen when online]

Hi guys,

I'm using my trusty netbook today, and whenever I go online with the controller, and click on an operand to view/change it's value, the little pop-up window is off-screen. I know it's there because I can toggle MBs by hitting the "enter" key on the keyboard, but it isn't visible.

A while ago, Saragani suggested changing the values in oplc.ini under heading [2000], the values being 2001 and 2002. The problem is, this only affects the operand data entry window on the screen while programming in off-line mode, and has no effect on the operand form that pops up while online.

Is there a set of values I can change to get this pop-up back on screen?

Thanks,

TM

[New feature for List of Text Variable]

I've used a similiar method when creating part number selection screens, although I use data tables to store the information relative to the part number. One thing I do differently is to replace the buttons along the side with a scroll bar, to make moving through the list easier.

[New feature for List of Text Variable]

And before it comes up, I know about the OS Alarms feature, and have used it before. I've even instructed a couple of people in how to use it. It's a great feature, but honestly, it's just not to my personal taste. On this one, I prefer to "roll my own", so to speak.

TM

[New feature for List of Text Variable]

By the way, the date/time stamps on the alarm history above are a particularly nice tidbit that has been around for years, but I never realized the usefulness of until this project. I used to put the date and time from SI into MI and display it in a couple of ways, either directly as numerical display or converting to string first. Either way was clumsy and used alot of operands.

Now I use the UTC time functions. Use RTC to UTC FB to store each stamp into a single DW, then use the Display UTC variable to UTC variable to display it without any ambiguity (MI) or extra work (ASCII).

Nice feature! It's embarassing it hid below my radar for so long.

TM