Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - fohdeesha

Pages: 1 2 [3] 4
31
Tips & Tricks / Re: More than just PLCs
« on: September 14, 2014, 05:27:38 AM »
I've also had no problems pulling power usage information from a Wattnode - http://www.ccontrolsys.com/w/WattNode_Modbus

AdvancedHMI is working great to poll the device and display house kwh usage, amperage, voltage etc. Great program!

32
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!

33
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

34
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

35
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

36
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 : )

37
So I just tested v3.6.6, and everything is working perfectly!

I can now read and write everything without issue. I can read single coils and write them with no problem. Thanks so much for working on this so quickly! AdvancedHMI just became compatible with a LOT more PLC's : )

38
Version 3.66 has been posted that has a fix for writing to output bits (function code 5)

Awesome! However the download seems bugged? Whenever I go to download it on sourceforge, it just times out trying to connect to the download server. I tried all the sourceforge mirrors too, nothing seems to work : (

edit: SF just started working again. will test and report back

39
Support Questions / Re: Bug in the ModbusRTUCom Ver AdvancedHMIBeta363
« on: August 22, 2014, 09:52:19 AM »
check the discussion over here - http://advancedhmi.com/forum/index.php?topic=410.msg1433

with build 3.65 he just pushed, reading coils works great now. however still some weird issue with writing (function code 05)

40
Ok.  Well there has to be something i am missing when it comes to adjusting addresses, and i can't figure it out.

The modbus RTU driver is currently bugged so it won't work properly even if you do exactly as you're supposed to. Archie pushed a new build out about an hour ago, this fixes the reading of bits, however writing to bits (as you're trying to do to control your fan) is still not working for some reason. You should follow our thread here, some good info - http://advancedhmi.com/forum/index.php?topic=410.msg1433#msg1433 - pretty much everything in there is relevent to what you're trying to do as I also have a Koyo PLC and was driving myself crazy : )

Koyo uses weird addresses for holding/output bits, like 3082. The function code needed for these bits is 01 read/05 write. As you can see from the code Archie posted above, to get advancedhmi to use those function codes, it has to see a zero at the very beginning of the address. So you were absolutely correct to put a zero in front of the address to end up with 03082. With the latest build you should now be able to read that bit without any problems (and any other bits, as long as you're sure it begins with a zero if the PLC wants to see a read function code of 01).

The Koyo inputs (eg 12049) only support a read function code of 02, and as you can see from the code archie posted above, to get advancedhmi to use that read function code, it wants to see a 1 at the beginning of the address you enter. So that works itself out, and you don't need to add anything to the input addresses. An easy way to remember where to put stuff in advanced hmi is the plcaddressvalue box is where you enter the plc bit you want advancedhmi to display the status of, eg whatever controls the light on the button component. the plcaddressclick is what plc address actually gets controlled by a click of the button in the software.

For what it's worth you don't need ot do any special address conversion. Just find the normal modbus address of the bits in the PLC software. I don't know how much different the software for the DL line is, but in the software for my Click, in the address picker you can click "display modbus addresses" and itll show the addresses and function codes needed. just use those addresses adding a zero at the beginning if needed. I made a picture to try and help:








Hope that helps! Doing the above with the latest build (3.65) will work to read any bits but still can't write them yet. hopefully soon!

41
Support Questions / Re: ModbusRTU Major bug? Please help :(
« on: August 22, 2014, 08:59:59 AM »
Version 3.65 is now posted.

I appreciate the testing and feedback

That was quick! Upsides and downsides:

Just tested - reading of ALL register types now works great! I can successfully read integers, holding bits, and input bits (and output bits of course as they use the same function codes as holding bits). The Automation direct PLC's input registers all begin with 1 (eg 100006) so that automatically gets us the 02 read function code we need to work properly right off the bat.

However the click PLC's holding bits and output bits all begin with weird numbers (eg 8194 for output 2 or 16385 for holding bit C1). Simply adding a zero in front of these numbers when using them in AdvancedHMI works exactly as expected, and gets us the proper function codes. EG: 08194 in advanced HMI will read the output bit located at 8194 with read function code 01 (as advancedhmi uses the function codes 01 read and 05 write when it sees addresses beginning with zero). I'm sure you know all this but just making sure to be verbose in case any other lost RTU users are following this thread : )

Now the bad news: Reading any kind of address is working great, but I simply cannot get advancedhmi to write to any bits at all. No matter what I do it just does nothing, like the plc isn't even seeing any requests coming in or the requests are seeing the wrong function code. I tested writing to holding bits and outputs bits that support being written to, and it just won't happen. I tested toggle switches, momentary set switches, write value switches, etc. Just doesn't do anything. But it reads all of these same bits just fine.

Thanks so much for making some headway on this! I will definitely be purchasing your button/meter packs later tonight. Let me know if there's anything else I can help with

edit: I'm sure you've seen, but this guy posted some code modifications that may fix the writing of coils (function code 05)? - http://advancedhmi.com/forum/index.php?topic=403.0

42
Support Questions / Re: ModbusRTU Major bug? Please help :(
« on: August 22, 2014, 06:14:49 AM »
I have a fix to reading inputs, for example address 10001 (function code 2). I will post it later today.

Well I'm reading simple store bits and output bits that use read code 01, for instance 08194. I work from home and have a modbus rtu plc sitting next to me at all times so I'm available for any rtu testing if you need, I'd love to test any fixes as soon as you can send them over! fohdeesha@gmail.com

43
Support Questions / Re: ModbusRTU Major bug? Please help :(
« on: August 22, 2014, 03:51:56 AM »
A new version (verison 3.64) has been posted with a fix to the ModbusRTU driver. Try this version and see if it is any closer.

Thanks so much for looking into this! Sadly I just downloaded the new version, and I'm still having the same issue. I can successfully read integer addresses and display them, but I cannot read/write the status of bits. if I use a light indicator, it displays on no matter what the actual bit is doing :(

I checked to make sure it wasn't just an off by one error or something simple, but no matter what it won't work

44
Support Questions / Re: ModbusRTU Major bug? Please help :(
« on: August 08, 2014, 08:18:47 PM »
This bug has been addressed and a fix will be included in the next release.

As for the first didgit/function code, that addressing technique was chosen because of its common use. I personally find it to not make much since because the first digit doesn't always coincide with the function code number.

That's awesome Archie! Thanks so much for the quick response. Is there any way I can help test this version ahead of time, or do you have a guess as to when it will be publicly available? I'm really itching to get this HMI installed :)

45
Feature Request / Re: Automation Direct Drivers
« on: August 08, 2014, 07:25:14 PM »
Have you given any thought to Drivers for Automation Direct PLCs? Like the Do-More, Direct Logic, Click and Productivity Line?

You can interface with all of the listed PLC's just fine using the new modbus RTU driver (modbus over serial). However there is currently a pretty serious bug in the RTU driver that prevents advancedhmi from properly reading/writing coils (I made a thread about it here - http://advancedhmi.com/forum/index.php?topic=410.msg1433#msg1433 ) Hopefully it'll be working soon! I can currently read integer registers off a Click, but nothing else : (

Pages: 1 2 [3] 4