Messages

1

Support Questions / Message display by value in reverse

« on: November 22, 2015, 11:48:05 PM »

Hi Archie,
Is there a control or some technique to allow a PLC value to be updated according to a value from a list (maybe a dropdown list)?

What I am looking for is almost the exact inverse of the "message display by value" or ideally a way to add a feature to the "message display by value" so that, in addition to the existing functionality, the message list could be used to allow the user to select a message and set the PLC to the corresponding numeric value from the list.

Regards,
Ron

2

Support Questions / Re: LinearMeterV target value scaling

« on: October 06, 2015, 03:22:04 AM »

Thanks for the quick fix. Problem solved (I am running 3.99a).
Just so you know... the new property appears to have a typo ScaleTargetVale (u missing).

I also ran into another problem with this control when a comms error (using ModbusTCP) caused an error in CDbl(). My fix in LinearMeterVert.vb starting at line line 42 is this:

                If ValueScaleFactor = 1 Then
                    MyBase.Text = value
                Else
                    'in case value contains a comms error message - cannot convert to Dbl
                    Try
                        MyBase.Text = CDbl(value) * ValueScaleFactor
                    Catch ex As Exception
                        MyBase.Text = value
                    End Try

                End If

I think these two issues (target scaling and issue with a comms error) also apply to the horizontal version LinearMeterH. I haven't tried this one as much as the vertical version.

Regards,

Ron

3

Support Questions / LinearMeterV target value scaling

« on: October 05, 2015, 08:45:57 PM »

Hi,
I have a LinearMeterV set to display 0-100.0% from a PLC value that is 0-1000 (value scale factor = 0.1). This works fine.
The target value from the PLC is scaled the same way, however the target value display isn't scaled when it is displayed. It doesn't seem to be influenced by the value scale factor.
Is there some way to scale the target value, either the same as the value or independently?

Regards,

Ron

4

Support Questions / Re: Modbus TCP access to unimplemented functions

« on: October 04, 2015, 08:37:59 AM »

Hi Archie,
Updating to 3.99a solves the problem of received packets for the unimplemented functions not getting through - thanks.
Now a different problem on the sending side...
For the two new functions I am implementing (8 and 43), everything seems to work fine when there is only one of the new commands used (eg in a basic label). If I have a few of them on the same page eg 8:00011 8:00012 8:00014 etc some of them work and some don't. Each of them works fine if used by itself. The presence or absence of controls using the standard Modbus function codes does not appear to make any difference. A little checking shows that the ones that don't work never get through to BeginRead(). I imagined that they might be getting eaten by the code that does the bit read optimisation for "coils", so I tried adding 40000 to all the addresses (eg 8:40011 etc) and subtracting the 40000 in BeginRead(). This seemed to make no difference. Is there some easy way to disable the read address optimising logic, just for a test?
Regards, Ron

5

Support Questions / Re: Modbus TCP access to unimplemented functions

« on: October 01, 2015, 06:56:16 PM »

I am using Ver 3.99  (AdvancedHMIBetaV399.zip).
Please let me know if I should re-test with 3.99a

6

Support Questions / Re: Modbus TCP access to unimplemented functions

« on: October 01, 2015, 05:25:36 PM »

Here is the response packet...

7

Support Questions / Re: Modbus TCP access to unimplemented functions

« on: October 01, 2015, 10:02:10 AM »

Hi Archie,
Thanks for your comments.

The 43:000x syntax works to a point, however the PDU sent is not formatted correctly. I fixed  this with a some special treatment just for function code 43 in the BeginRead function in ModbusBase.vb. This all works and Wireshark shows the correct packet being sent and the expected response coming back.

Somehow this response seems to get lost somewhere. The DataLinkLayerDataReceived function in ModbusTCPCom.vb never gets called.
If I understand the workings of this, I'm thinking that it would be called by the Modbus TCP driver DLL. Is there some kind of filtering in the DLL to reject incoming packets that maybe don't follow the rules for the implemented Modbus functions?

The response Modbus PDU (as per Wireshark) is 60 bytes, in case length is an issue.

Regards,
Ron

8

Support Questions / Modbus TCP access to unimplemented functions

« on: September 30, 2015, 09:57:19 PM »

Hi,
I have an application that needs to read some of the Modbus function code 08 (diagnostics  - error counters etc) and also read the slave device identification - function code 43. I understand that these function codes are not supported in AdvancedHMI.

These are part of the Modbus standard, but not all that commonly used, so I understand why they are not implemented. I am certainly not suggesting they should be, just looking for a work around.

In order to access these less common functions and possibly others, is it possible to call some existing low level function (maybe the data link layer) with a string etc containing the Modbus query (ie the PDU) to be sent  and then receive the PDU from the reply as a raw un-parsed string into the text property of a control or another callback function etc?

Ron

9

Support Questions / Re: Modbus TCP: Button to clear several coils at once

« on: September 29, 2015, 09:25:29 AM »

Hi Archie,
Your suggestion works well - thanks.
I notice it also works in the click event of a PilotLight like this:

    Private Sub PilotLight4_Click(sender As Object, e As EventArgs) Handles PilotLight4.Click
        ModbusTCPCom1.Write("00001", "0")
        ModbusTCPCom1.Write("00002", "0")
    End Sub

Is there any problem with using a PilotLight like this?

Ron

10

Support Questions / Modbus TCP: Button to clear several coils at once

« on: September 29, 2015, 08:42:57 AM »

Hi,
I have an application using Modbus TCP to control a VSD that has separate "coils" for forward and reverse operation. To stop, I need to clear both "coils". Is there a way for a single button to write the same value (in this case reset) to more than one "coil" address?

Regards,
Ron