direct logic 05 and ModbusRTU com driver

[fohdeesha]

I fixed and reworked a number of things with the ModbusRTU driver. It's now more responsive and recovers quickly from a loss of communications. It seems to be quite stable now with version 3.68

You continue to amaze! My little project has been working flawlessly with 3.67, but will grab the new update! I will definitely be making a nice video showcasing the project and how integral Advanced HMI is once the project is finished : )

[BW]

I just tested an AutomationDirect Click PLC with Version 365 using Modbus RTU.
The X inputs worked fine, but the Y outputs did not.
I downloaded the latest Version370beta.
The AdvancedHMIDrivers Components are missing?

[Archie]

I just tried version 3.70 in Visual Studio 2010 and it worked. Do you get any errors when you do a Rebuild All? This may be a basic question, but did you unzip the file? If you try to browse into the zip file and open it, VS will give errors.

[Archie]

Just to make sure the version on sourceforge was not corrupt, I downloaded it, unzipped, opened in VS2010, and did a Rebuild All. I then opened Mainform and checked the toolbox to make sure everything was there. It was all correct.

[fohdeesha]

Hey Archie, thanks again for working so hard on this. I've ran into a "problem", or maybe my expectations are unrealistically high.

Whenever I add more than two or three meters and a button, they eventually fail to update properly, and the button becomes unresponsive. Especially if I click the button maybe once every second or two, it eventually times out and the meters give up and won't update anymore and the button stops doing anything.

I increased poll rate override to 1000 (one second) and it seems to help a little bit, but eventually if I hit the button too quickly (not super quick, but maybe once every couple of seconds) it seems to clog up the tubes and lag out.

I'm using a baud rate of 115200, and I guess I thought with that speed I'd be able to update a couple of buttons and meters faster than once a second. I mean, my math is pretty bad, but wouldn't that many bits come out to a LOT more meters and buttons before overflowing?

Maybe I'm doing something wrong or have false expectations. I can keep trying to increase the poll rate, however at one second it's already becoming too slow for my specific application, and it's only going to get worse when I add more meters and buttons.

Here's what the meters eventually look like. Sometimes they look like this right when starting the application, and will flicker a value every once in a while, but go right back to this - http://i.imgur.com/1W6z3bc.png

Oddly when I switch out the meters from the blue meters in the paid meter pack, for the stock panel meters, it's a little bit better, but the same problem. However they don't time out or give up nearly as easily - http://i.imgur.com/nIaKRnS.png

I'd actually like to use the above red meters, but the decimal point obscures the numbers. Is there any way for me to change that?

Thanks so much for working on this driver, I feel bad constantly reporting issues but it's working so well other than that!

I'm getting the same effect in 370, 369, and 363. However it is the worst in 370. a tiny bit better in 369

Oh, I noticed on the comm status light on my PLC next to the serial port, when the HMI is running, it blinks very erratically. Like advancedhmi is polling it very erratically, not steadily at the set poll rate

[neptun2002]

Hi with ver 3.70 you have not to have this problem I have test it whithe 32 buttons and four meters holding registers and four input registers with tow PLCs in the same time and it worked perfect even with pooloveridde 0

I think you have a problem with your communication wires try to decreas the buade rate

And test again
Pleas look this picture

http://i.imgur.com/5dXN9is.png


Good luck

[fohdeesha]

I think you have a problem with your communication wires try to decreas the buade rate

Thanks for the fast reply. I have already tried every baud rate available and the problem remains. Other programs using the same serial to plc interface work perfectly at any baud rate and do not have this kind of slowing/poll rate problem.

Just for a quick test, I made a simple brand new project in 3.70, using three panel meters reading integer holding registers. No matter what baud rate, the third one just refuses to poll and display. Interestingly it's really bad like this with the purchased blue meters from the meter pack I bought. If I use the stock panel meters, all three will at least update, but very slowly/sporadically. Interesting how much worse the blue ones are though. see here - http://i.imgur.com/bXn0p4u.png

Any other ideas? I'm up to try anything

[Archie]

When I was doing my testing , I used a 38400 baud rate and a PollRateOverride of 50, which is the fastest it will let you go. I had 5 BasicLabels with addresses of 40001-40005

I had another BasicLabel pointing to a Boolean. And another BasicLabel pointing to a timer accumulator. And finally 5 SelectorSwitches.

I ran this for 8 hours with a counter I put in the program to track any errors and missed packets. After 8 hours no errors were counted.

The only thing I can suggest is to use a serial sniffer to see if the PLC is responding to all requests. Free Serial Port monitor is easy to use if you have a 32 bit operating system. Otherwise Device Monitoring Studio has a trial package.

[Archie]

Try using BasicLabels in place of the meters. A BasicLabel can show errors that meters are sometimes not capable of showing.

[fohdeesha]

Once again thank you so much. I tried the exact baud rate you mentioned, 38400, and the problem is totally gone. I have a bunch of meters and buttons now and no lag. That is very strange, last night I tried nearly every other baud rate and was getting that problem. It's very possible this cheap plc just times out when using faster baud rates, but I've always used 57600 with other applications and have never noticed a problem. Maybe they were just covering it up.

Thanks so much! Is there any way I can move the decimal points or increase the space between the letters on the red gauges so the decimal point doesn't collide with the numbers? - http://i.imgur.com/HcdyFHT.png

[Archie]

I will try it at the higher baud rates. The Modbus specification requires a pause of communications (silence) of 3.5 characters to distinguish different packets. Since this is specified in characters, the time gets shorter as the baud rate increases. It also says to use a minimum time when going above a certain baud rate. I have a feeling this may be the issue that you are seeing because I have not tested  the driver any faster than 38400.

As for the meter, I will fix the decimal problem for the next release.

[fohdeesha]

Ah, that would make sense. Like I said earlier, it's totally possible it's my PLC's fault given how cheap it is. But I'm 100% satisfied at 38400, it's super responsive.

Thanks for working on this. I feel spoiled to have this program for free!

[stilesbss]

Hello Everyone.

I had to set my project down for a while as other things came up, but I'm back at it and I have one more issue to solve before i am fully up and running.

I have meters monitoring 4 timers and 2 counters.  I have noticed that they don't count in decimal.  When i start my runs the seconds timer counts 1-9 then jumps to 16 and counts through 25, then jumps to 32 and counts to 41, then jumps to 48 and continues in that pattern.

In previous versions the Modbus RTUCom had the option to  TreatDataAsHex, which when selected my timers and counters would display the correct values.   I can not find that option in the 370 version.  Is there another way to convert the data from hex to decimal so my displays with show the correct values?

Thank you all.

[fohdeesha]

In previous versions the Modbus RTUCom had the option to  TreatDataAsHex, which when selected my timers and counters would display the correct values.   I can not find that option in the 370 version.  Is there another way to convert the data from hex to decimal so my displays with show the correct values?

Can you get those timer outputs into integer registers? if so then you could use this method to display decimal accuracy - http://advancedhmi.com/forum/index.php?topic=441.msg1660#msg1660

(apologies if that's not relevant at all, I haven't begun to play with timers yet. but if it's just a number output, floating point or real, you can multiply it and stick it in an integer register then add a decimal point with the meters

[stilesbss]

No worries.

I don't need decimal points.  I'm just keeping track of run time in seconds, minutes, hours, and days.  The timers however seem to be counting up in a weird form of hexadecimal.  it will count up from 1-9 then jump to 16 and count up 28 then jump to 35 and so on.

The counters are doing the same thing, so it must be pulling the value strait from the v-memory location with out converting it.  I am trying to find a command in DirectSoft 5 that will let me convert the value in the timer memory to decimal so i can have the meter pull the value from there but i have not found anything yet.

If i knew more about VB i could probably perform the conversion in the code, but i am unsure of what command to use and where i should put it.

I will keep searching the google and checking back here until i find a solution.