AdvancedHMI Software
General Category => Support Questions => Topic started by: stilesbss on August 19, 2014, 09:55:59 PM
-
Hi there. I am really new to the world of PLCs but I must say that the communities are amazing. Everywhere I have gone with questions the people are just awesome.
I have a few questions about connecting a DL05 using the modbus RTU driver.
When setting an address for the the objects there are 4 plcaddress lines, each with a different ending. Do they do different things? Are they used for different objects? Should each object use one spot, or should all 4 be filled?
Also, which method should be used for adjusting the plc addresses to modbus addresses when directing an object.
That should be it for now. I have a lot more questions, but many of them depend on what I have already asked.
Thank you everyone for your help.
-
When setting an address for the the objects there are 4 plcaddress lines, each with a different ending. Do they do different things? Are they used for different objects? Should each object use one spot, or should all 4 be filled?
As a general rule, the name after PLCAddress is the property that gets changed based on the value returned from the PLC. For example, if you put a valid address in PLCAddressValue, it will read the value from the PLC and place it in the Value property of the HMI object. In design mode, you can see the effect this has by manually putting a value into the corresponding properties.
-
Thank You. That was very helpful.
Now i am trying to get the buttons working. I am not even sure what questions i should be asking so i'm just going to discribe what i am doing.
Using my fan control as an example it.
It is controlled by the C11 control relay. using the directlogic to modbus address conversion i should be using 3082 as the address. Advanced HMI won't take 4 digit addresses so i am assuming that i add a 0 to the front making it 03082 and put that in the plcaddressclick cell. Then i set the output type to toggle and that should be it, but it doesn't seem to be working.
I can only guess that i am not using the correct address, or i have to add something in the ladder logic to let it be used by the hmi. Any advice is appreciated.
Thank you again for the help.
-
Use 30082
-
Nope that didn't work either.
-
Does it say which function code and element number to use?
-
Thats kind of what i'm trying to find out. There is a few different ways to calculate the address.
What i have been doing is the following: 584/984 Mode Address
CR take the octal adddress c11 convert it to decimal 9.
Add start of modbus address range, which for control relays is 3072
then add 1 for the mode address.
There is another section that talks about modbus function code. I think for this it would be function code 05. set/reset a single coil.
but the none of the address calculations use the function code. one is what i have done above, and the second converts octal to decimal, then adds a range, then you put a data type in front of it, so C11 would be Coil 3081.
Thank you again for helping.
-
I think for function code 1 your address would be 10038
-
The AdvancedHMI driver uses the first digit of the address to determine a function code, however it is not a 1:1 relationship. This is how it translates the address to function code:
Select Case CInt(AddressFirstDigit)
Case 0 : m_ReadFunctionCode = 1
WriteSingleFunctionCode = 5
WriteMultiFunctionCode = 15
m_BitsPerElement = 1
Case 1 : m_ReadFunctionCode = 2
WriteMultiFunctionCode = 0 '* Invalid
m_BitsPerElement = 1
Case 3 : m_ReadFunctionCode = 4
WriteMultiFunctionCode = 0
m_Element = CInt(Address.Substring(1)) - 1
m_BitsPerElement = 16
Case 4 : m_ReadFunctionCode = 3
WriteSingleFunctionCode = 6
WriteMultiFunctionCode = 16
m_Element = CInt(Address.Substring(1)) - 1
m_BitsPerElement = 16
-
Ahh ok. thats helpful. Thank you. I will take another crack at it and let you know how I fair.
-
Ok. Well there has to be something i am missing when it comes to adjusting addresses, and i can't figure it out.
i have not gotten any of my buttons to work. So i took a step back and am going to try to attack it from a different perspective, i set up a pilot light and connected it to the X0 input of my plc. Looking at my manual X0s modbus address should be 12049, and it is. Using that address i am getting the pilot light to show when X0 is on and off, and if follows X0, so if i manually disconnect X0 the pilot light goes out.
X1 is being used in the same fashion as X0, using the same adjustments for the address the modbus address of X1 should be 12050, but when i put that into a second pilot light it does not work and returns an A1/E1 error message about an invalid value returned.
Is there something i'm missing? Do i need to make timing adjustments so its not trying to read everything at once.
Its just weird that i can get some stuff to work using the modbus address calculations in my manual and others dont.
Once again thank you for any help you can provide. I really appreciate it. That is a fantastic program and i'm really new at this so Thank YOU.
-
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:
(http://i.imgur.com/BLjuBgH.png)
(http://i.imgur.com/c6bXErU.png)
(http://i.imgur.com/Aij4lIZ.png)
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!
-
Awesome!. That helped a bunch and made me feel a lot better.
I got the new revision and took a crack at it this morning. Initially i was having the same problems that i have been having. The biggest example of this is my indicator light for inputs x0 (12049 modbus) and x1 (12050 modbus).
When i started only x0 was working correctly and x1 was giving my an error message. I finally had a eureka moment though. I had set my COM value TreatDataAsHex to true, because otherwise the meters i have set up to watch various timers and counters don't show the correct value, but that had been messing with my indicators.
I changed the COM setting for TreatDataAsHex to false and bam, xo and x1 are reading properly, buttons for my various internal relays are at least illuminating properly when the relay is on...and actually will turn the relay off, though not back on, but that was expected.
So, i am back on track to get this working pending a fix for the COM driver and i can figure out how to get some of my objects to have the data treated as hex and others not, but i am pretty sure i can work that out in the code.
Thanks you fohdeesha, and Thank You Archie, you are Awesome.
-
Version 3.66 has been posted that has a fix for writing to output bits (function code 5)
-
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
-
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 : )
-
Thanks for the testing and feedback. The ModbusRTU driver sat unfinished for over a year because it was not easy for me to test. I finally decided to release it "as is" in hopes of getting feedback so I could get it finished up. Appreciate the help and patience in getting it finished. The next unfinished driver I hope to get completed soon is for all the Omron PLCs.
-
Dear Archie Pleas Have a look to the attached File
thanks
-
Dear fohdeesha try to write single register (function 6) it will not work not fixed yet you will have always the value 1 written into register
I mentioned how I solved this point in my previews reply
also try to use more than eight coil registers in series let us say 24 coil registers in series (10001 -10024) it will not work because of the bug I just mentioned
for me with the Points I posted the code now it is working great for
function (0x01) Read Coils
function (0x02) Read Discrete Inputs
function (0x03) Read Holding register
function (0x04) Read Input register
function (0x05) Write Single Coil
function (0x06) Write Single Register
still have to test the rest of the Modbus RTU functions which are the
Write Multiple Coils (0x0f)
Write Multiple Registers (0x10)
Thanks
-
Dear Archie Pleas Have a look to the attached File
thanks
This was addressed and fixed in version 3.66
-
Sure There is some Thing wrong with me Archi I checked again I am Testing Ver 3.66 now I can see the code as Follows
public ModbusPDUFrame(byte[] packet, int length, int offset)
{
this.FullPacket = new List<byte>();
if (offset < 0)
{
offset = 0;
}
this.m_FunctionCode = packet[0 + offset]; '<--------------------------------------------------- This One
if ((this.m_FunctionCode >= 0x80) && (packet.Length > 1))
{
this.m_ExceptionCode = packet[1 + offset];
}
else
{
this.m_ExceptionCode = 0;
}
this.m_EncapsulatedData = new List<byte>();
if ((length + offset) > packet.Length)
{
length = packet.Length - offset;
}
int num2 = length - 1;
for (int i = 2 + offset; i <= num2; i++)
{
this.m_EncapsulatedData.Add(packet);
}
}
Thanks
-
Sure There is some Thing wrong with me Archi I checked again I am Testing Ver 3.66 now I can see the code as Follows
The fix was done in the ModbudRTUFrame, so it would not affect any other classes that use the ModbusPDUFrame:
'**********************************
'* Extract data from a packet
'**********************************
Public Sub New(ByVal packet() As Byte, ByVal length As Integer)
m_StationAddress = packet(0)
m_PDU = New Modbus.ModbusPDUFrame(packet, packet.Length - 2, 1) <----------
End Sub
-
Yes Archie I saw it But Now every thing I gut Right before is wrong
I think we have to change every call of this function the same way to solve the problem also I wonder as we know from the structure of the Modbus telegram that is the second byte is the function code so what is the necessity to have the offset in this case as we need the function code itself nothing else ??!!
Thank you so much Dear
-
Yes Archie I saw it But Now every thing I gut Right before is wrong
I think we have to change every call of this function the same way to solve the problem also I wonder as we know from the structure of the Modbus telegram that is the second byte is the function code so what is the necessity to have the offset in this case as we need the function code itself nothing else ??!!
ModbusTCP does not have the same packet, so if the offset was changed in ModbusPDU, then the class could not be used to extract ModbusTCP packets.
And yes, you are right, every call to the PDU class from the RTU class has to be changed (which is only one other location).
-
Now I get it Back to work Just subtract The One we Added to offset
Public Sub New(ByVal packet As Byte(), ByVal lengthOfThePacket As Integer, ByVal offset As Integer)
Me.FullPacket = New List(Of Byte)
If (offset < 0) Then
offset = 0
End If
Me.m_FunctionCode = packet((0 + offset))
If ((Me.m_FunctionCode >= &H80) AndAlso (packet.Length > 1)) Then
Me.m_ExceptionCode = packet((1 + offset - 1))
Else
Me.m_ExceptionCode = 0
End If
Me.m_EncapsulatedData = New List(Of Byte)
If ((lengthOfThePacket + offset - 1) > packet.Length) Then
lengthOfThePacket = (packet.Length - offset - 1)
End If
Dim newPacketLength As Integer = ((lengthOfThePacket + offset - 1) - 1)
Dim i As Integer = (2 + offset - 1)
Do While (i <= newPacketLength)
Me.m_EncapsulatedData.Add(packet(i))
i += 1
Loop
End Sub
I think the best way Is to make a new method especially for RTU
Now with these changes I have Good result
-
Me.m_FunctionCode = packet((0 + offset))
If ((Me.m_FunctionCode >= &H80) AndAlso (packet.Length > 1)) Then
Me.m_ExceptionCode = packet((1 + offset - 1))
Else
Me.m_ExceptionCode = 0
End If
There is a problem with this code. It will set the Exception code to the same value as the function code. The exception code is in the data byte position.
-
Yes You are Right About this point Archie. I did not take care enough to this point as it is not affect the run in normal condition so as I suggested yesterday I found that adding a new version of ModbusPDUFrame Dedicated for RTU and Leave the Old one for TCP as is will be one possibility and the code should be like this
Namespace MfgControl.AdvancedHMI.Drivers.Modbus
Public Class ModbusPDUFrame
'***************** The old Method Dedicated For TCP And whatever other callers need AS Is no thing changed
Public Sub New(ByVal packet As Byte(), ByVal length As Integer, ByVal offset As Integer)
Me.FullPacket = New List(Of Byte)
If (offset < 0) Then
offset = 0
End If
Me.m_FunctionCode = packet((0 + offset))
If ((Me.m_FunctionCode >= &H80) AndAlso (packet.Length > 1)) Then
Me.m_ExceptionCode = packet((1 + offset))
Else
Me.m_ExceptionCode = 0
End If
Me.m_EncapsulatedData = New List(Of Byte)
If ((length + offset) > packet.Length) Then
length = (packet.Length - offset)
End If
Dim num2 As Integer = (length - 1)
Dim i As Integer = (2 + offset)
Do While (i <= num2)
Me.m_EncapsulatedData.Add(packet(i))
i += 1
Loop
End Sub
'***************************************************************
'***************** The New Added One Dedicated For RTU tailored on the RTU Requirements
Public Sub New(ByVal packet As Byte(), ByVal lengthOfThePacket As Integer, ByVal offset As Integer, ByVal It_Is_RTU As Integer)
Me.FullPacket = New List(Of Byte)
If (offset < 0) Then
offset = 0
End If
Me.m_FunctionCode = packet(1)
If ((Me.m_FunctionCode >= &H80) AndAlso (packet.Length > 1)) Then
Me.m_ExceptionCode = packet(2)
Else
Me.m_ExceptionCode = 0
End If
Me.m_EncapsulatedData = New List(Of Byte)
If ((lengthOfThePacket) > packet.Length) Then
lengthOfThePacket = (packet.Length)
End If
Dim newPacketLength As Integer = (lengthOfThePacket - 1)
Dim i As Integer = 2
Do While (i <= newPacketLength)
Me.m_EncapsulatedData.Add(packet(i))
i += 1
Loop
End Sub
'Stop **********************************************************************************
Namespace MfgControl.AdvancedHMI.Drivers.ModbusRTU
Public Class ModbusRTUFrame
Public Sub New(ByVal packet As Byte(), ByVal length As Integer, ByVal RTU As Integer)
Me.FullPacket = New List(Of Byte)
Me.m_StationAddress = packet(0)
'***********************************
Dim Offset As Integer = 1
Dim Is_It_RTU As Integer = 1
'***********************************
Me.m_PDU = New ModbusPDUFrame(packet, packet.Length, Offset, Is_It_RTU)
End Sub
Namespace ModbusRTU
Public Class ModbusRTUCom
Dim IT_IS_RTU As Integer = 1
Dim RTU As New ModbusRTUFrame(New List(Of Byte)(e.RawData).ToArray, e.RawData.Count, IT_IS_RTU)
Now It is work Great
Thank you so much dear
-
Version 3.67 has been posted that fixes a writing problem to holding registers such as address 40001
-
Thank you so much Archie for your efforts in this project
I tested the new version its work great when number of elements is les than 8 that means one byte so I made a small change and it is working great now
thanks
Private Function ExtractData(ByVal RawData As List(Of Byte), ByVal startByte As Integer, ByVal address As ModbusAddress) As String()
Dim values(address.NumberOfElements - 1) As String
Dim NumberOfBytes As Integer = CInt(Math.Ceiling(address.BitsPerElement / 8))
Dim i As Integer
While i < address.NumberOfElements And (startByte + i) < Math.Floor(RawData.Count / NumberOfBytes)
'Dim HexByte1 As String = Chr(RawData(startByte + i * NumberOfBytes)) & Chr(RawData(startByte + (i * NumberOfBytes) + 1))
If NumberOfBytes > 1 Then
'Dim HexByte2 As String = Chr(RawData(startByte + (i * NumberOfBytes) + 2)) & Chr(RawData(startByte + (i * NumberOfBytes) + 3))
If Not m_TreatDataAsHex Then
values(i) = CStr(RawData(startByte + i * NumberOfBytes) * 256 + RawData(startByte + i * NumberOfBytes + 1))
Else
values(i) = CalculationsAndConversions.ByteToHex(RawData(startByte + i * NumberOfBytes)) & CalculationsAndConversions.ByteToHex(RawData(startByte + i * NumberOfBytes + 1))
End If
Else
If Not m_TreatDataAsHex Then
If address.BitsPerElement > 1 Then
values(i) = CStr(RawData(startByte + i * NumberOfBytes)) ' + 1)) removed 21-AUG-14
Else
'* It is a bit read, so extract from the byte
Dim BitNumber As Integer = 0
'**The Bug********************************************************************************************
'While ((i + BitNumber) < address.NumberOfElements) And (BitNumber < 15) '<------------This one Because it is byte
'values(i + BitNumber) = CStr((((RawData(startByte + i * NumberOfBytes)) And CByte(2 ^ BitNumber)) > 0)) '<------------This one the location of the bit in the array
'**The Bug********************************************************************************************
'**The New Code ********************************************************************************************
While ((i + BitNumber) < address.NumberOfElements) And (BitNumber < 8) '< 15)
values((i * 8) + BitNumber) = CStr((((RawData(startByte + i * NumberOfBytes)) And CByte(2 ^ BitNumber)) > 0))
'**The New Code ********************************************************************************************
BitNumber += 1
End While
End If
Else
values(i) = CalculationsAndConversions.ByteToHex(RawData(startByte + i * NumberOfBytes))
End If
End If
i += 1
End While
Return values
End Function
-
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
-
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 : )
-
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?
-
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.
-
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.
-
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
-
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
-
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
-
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.
-
Try using BasicLabels in place of the meters. A BasicLabel can show errors that meters are sometimes not capable of showing.
-
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
-
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.
-
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!
-
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.
-
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
-
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.
-
Your data is coming back in BCD format which uses 4 bits to represent each digit. Hexadecimal does essentially the same thing, but instead of 0-9 it uses the full 0-F and that is why TreatDataAsHex worked. I removed that feature because it was complicating the debug process.
You can make the DigitalPanelMeter use BCD by making this minor change to DigitalPanelMeter.vb at line 326:
Private Sub PolledDataReturnedValue(ByVal sender As Object, ByVal e As MfgControl.AdvancedHMI.Drivers.Common.PlcComEventArgs)
Try
MyBase.Value = String.Format("{0:X}", e.Values(0))
Catch ex As Exception
DisplayError("INVALID VALUE RETURNED!" & e.Values(0))
End Try
End Sub
-
Awesome. Thanks Archie.
I will give that a try and let you know how it works out.
-
Hey Archie.
I modified the code, but am still getting the same readings.
I have tried to swap the values to look like (e.Values(0), "{0:X}"). I've tried replacing the {0:X} with just X. i've tried replacing the X in all variation with D.
Most iterations have no effect on the value displayed in the meter, the rest cause the program to not run.
I am going to keep looking up solutions, but any other ideas you have would be most appreciated.
-
There are 2 meters, DigitalPanelMeter and DigitalPanelMeterA. Make sure the one you modified is also the one you are using v
-
I got it to work.
I replaced
MyBase.Value = String.Format("{0:X}", e.Values(0))
with
MyBase.Value = Hex(e.Values(0))
My initial test worked. now i'm going to let it run for a while and see if it will keep count properly.
-
Just a quick update. I let the program run for 5 hours yesterday and everything worked beautifully. Thanks Archie.