Messages

46

Support Questions / V 396 error when adding purchased controls

« on: January 07, 2015, 06:04:43 AM »

Darrell/Archie,

I found another way to make this work and that is by adding "Imports Microsoft.VisualBasic" as shown below.
I have no idea why this would be necessary but it may help point to the problem.

Doug Lyons

47

Support Questions / V 396 error when adding purchased controls

« on: January 07, 2015, 12:26:18 AM »

Darrell,

I had the same problem as you and I added the "Microsoft.VisualBasic" Namespace as Archie noted and this did not help.
What I found was that if I added "Microsoft.VisualBasic.Strings." in front of the three function errors this fixed my problem.
I have attached a picture showing the details for the "LinearMeterVert.vb" and the "LinearMeterHoriz.vb".
I hope that this helps you with your problem.

Doug Lyons

48

Support Questions / NumericSevenSegment to count in reverse

« on: December 21, 2014, 11:09:24 PM »

Darrell,

Could you leave the "PLCAddressValue" blank in the NumericSevenSegment and add a DataSubscriber that has this code?

        NumericSevenSegment1.Value = 100 - e.Values(0)

Obviously the name I used has a "1" suffix, but you would have to match what your component has.
My tests seem to indicate that this will work.

49

Additional Components / Adding Custom Controls

« on: December 14, 2014, 10:55:42 PM »

MrPike,

I was able to do this, but I had to change the statement #9 to the following:

9) Change "Inherits MfgControl.AdvancedHMI.Controls.Meter2" to "Inherits AquaGage"

In other words the whole statement changes and you have to take out the dot and the AquaGage extension.
See if this fixes your problems.

50

Tips & Tricks / A Colorful Progress Bar / Bar Level

« on: December 09, 2014, 11:37:27 PM »

Archie,

Thanks for this great tutorial. I have gone through the steps and I had to do two more things.
Here is what I had to do between step 5 and 6:

5a) About 26 lines down you will see the code "Public Class BarLevel"
5b) Change this to "Public Class ProgressBarExHMI"

Without this I received this error:

class 'BarLevel' and class 'BarLevel', declared in 'C:\Users\lyonsdo\Documents\Visual Studio 2013\Projects\AdvancedHMIBetaV389\AdvancedHMIControls\Controls\BarLevel.vb', conflict in namespace 'AdvancedHMIControls'.   C:\Users\lyonsdo\Documents\Visual Studio 2013\Projects\AdvancedHMIBetaV389\AdvancedHMIControls\Controls\ProgressBarExHMI.vb

Thanks again.

51

Feature Request / Using Modbus Register Bits in Controls

« on: December 04, 2014, 08:20:24 PM »

Archie,

This code does seem to fix the ranges.
I noticed that this is a bit shorter than the old code and leaves out some checks for "F4" and "L4".
Does that mean that you do not handle the Floats and Longs anymore?

Also since the multi-threading improvements I have been getting error messages in the IDE.
when I use the "X" in the upper right-hand window to shut down the running project I received errors such as these:

A first chance exception of type 'System.ArgumentOutOfRangeException' occurred in mscorlib.dll
A first chance exception of type 'System.InvalidOperationException' occurred in System.Windows.Forms.dll
An unhandled exception of type 'System.InvalidOperationException' occurred in System.Windows.Forms.dll

I am guessing that the main form is closing out before some of the threads have a chance to close.
I do not know what happens when the EXE file is run, but I suspect that it would be fine.

I just wanted to let you know about this in case you have a solution.
The result is that you wind up in a debugging mode and then you have to use the "Stop" button to shut the program down.

I think that the poll time is defaulting to a very minimal value because my mod_RSSim shows lots of polls.
Also, my hard disk drive light stays busy and I think that the system is buffering lots of poll data.

Thanks again so much.

Doug Lyons

52

Feature Request / Using Modbus Register Bits in Controls

« on: December 04, 2014, 08:14:07 AM »

andrew_pj,

Yes. I get this same error. You can enter "-1" and you will see "65535" displayed with all bits set.
This appears to be just the difference in whether the 16-bit number is considered signed or unsigned.
In version 3.85 and before both inputs and outputs were handled as signed integers.
Now with version 3.86 it appears that the outputs are handled as unsigned integers and the inputs as signed integers.
Visual Basic has always had problems because of the fact that it is not a strongly typed language.
In the past there was no way to make an integer be unsigned. It was defaulted to signed.
There was no unsigned 16-bit declaration character or way to DIM the variable to unsigned.
This may have improved lately, but I do not know. I am very new to VB.net with much experience in VB6.

As you can imagine you can use "-1" through "-32768" on the keypad to get the full range of numbers with the high bit set.
It would be great if we were allowed to decide whether to use signed or unsigned integers for inputs and outputs.
Maybe this would be a good feature request.

53

Feature Request / Re: Using Modbus Register Bits in Controls

« on: December 04, 2014, 01:01:41 AM »

32768 cannot be written because the value is a signed integer and only the range -32768 through 32767 is accepted.

Archie,

From what I can see the above statement was true through version 3.85.
But with version 3.86 things seem to have changed.
Where before the Modbus registers were returning -32768 to 32767 now they return 0 to 65535.

I have attached a picture showing some examples. I copied a similar pattern to what andrew_pj used.
I noticed that his highest bit was 14, but I have included up to 15 to show all of the bits.

The HEX value is just a formula running in a DataSubscriber like the following:

Label1.Text = Mid("000" & (Hex(e.Values(0))), Len(Hex(e.Values(0))))

This is such a great program and allows a wonderful amount of flexibility since it is based on Visual Basic code.
Thanks for all of you work on this. I know that you must spend quite a bit of time on this.

54

Feature Request / Using Modbus Register Bits in Controls

« on: December 02, 2014, 08:39:45 AM »

Archie,

My preliminary testing indicates that this has fixed the errors that I was seeing.
Do you think that it would be a good idea to post a new version on SourceForge?

Thanks for the quick response and great work.

55

Support Questions / Modbus TCP Driver Failure in 3.84 & 3.85

« on: December 01, 2014, 09:16:55 PM »

Archie,

I am using the IP address of the Ethernet connection on my Motherboard which is 172.16.52.111.
Normally I do not use the 127.0.0.1 at all.
I had just plugged my laptop into my docking station when I was having the problems though.
Now all of the above items are working just fine, so maybe I had something wrong.
It would be nice to get the bits working for the ModbusTcpCom driver though.
I have done some testing in 3.86 and it seems that I can use .0 and .1 but not any other bits.

I have attached a screen shot of what I am seeing when I try and use bit 2.

Thanks very much for your continued support.

56

Support Questions / Modbus TCP Driver Failure in 3.84 & 3.85

« on: December 01, 2014, 11:37:56 AM »

Archie,

I have just tested the 3.86 version with only a ModbusTcpCom and DigitalPanelMeter with no success.
The error shows "Com Fail -- 20". I have attached an example of what I see.
I only tested address 40001. The attachment is named "3.84", but you can see the header shows "v3.86".

Thanks.

57

Support Questions / Modbus TCP Driver Failure in 3.84 & 3.85

« on: December 01, 2014, 08:59:33 AM »

Archie,

My testing was done using Modsim32 by Win-Tech Software on the same PC as the Advanced HMI.
The error has always been "Illegal Modbus Address" when using the DigitalPanelMeter.
For the BasicIndicator there mostly is no error, but the Bit values return incorrectly.
I am using Windows 7 in 64-bit mode.

Thanks very much.

58

Support Questions / Modbus TCP Driver Failure in 3.84 & 3.85

« on: December 01, 2014, 08:25:16 AM »

Archie,

I have not been able to make the ModbusTcpCom driver work with only a Digital Panel Meter for the 40001 register in version 3.84 or 3.85. I also tested registers 40002-40005 and these failed the same way.

The message at the top of the display shows the following:

INVALID VALUE RETURNED!Illegal Modbus Address

This happens regardless of what value I put into the registers.

Thanks for any help that you can provide.

59

Feature Request / Using Modbus Register Bits in Controls

« on: December 01, 2014, 08:08:00 AM »

andrew_pj,

I have had similar problems recently.

Unfortunately the ModbusTcpCom functionality will not even read a simple 40001 register into a DigitalPanelMeter since version 3.83. I tested 3.83 and it worked fine, but 3.84 and 3.85 both fail to even read a value. They give an error of "Illegal Modbus Address".

Hopefully Archie will be able to address these problems soon. I think it is likely that once this is fixed, the Bit reads will work again with the code modifications. If you can go back to a previous version that is 3.83 or before, you should be OK.

I tried to upload a picture of the error, but I received an error that the upload folder was full.

60

Feature Request / Using Modbus Register Bits in Controls

« on: November 15, 2014, 07:54:21 PM »

Archie,

This is very good. It does work if one is willing to make a few concessions with the Modbus address.
If the bit is 0 to 9 then everything works as expected (Ex: 40001.0 gets the LSB of the word).

A problem appears when using the standard 5 digit Modbus address with a two digit bit address.
Now you have more than 7 characters and you will see a message like that shown my first attachment above.
It says "Address must be 5-7 digits, xxxxx.xx" where the x's represent the address you tried to use.

The work-around is to shorten the Base Modbus address to 4 characters such as the following:

Example 40001.15 becomes 4001.15 and this works fine to get the actual Modbus address of 40001 and bit 15.

Thanks for the suggested code and the quick reply.
It seems that making the change all around would likely have minimum negative effects.
As a further clarification to anyone else who might want to test this code I have these comments.

This code needs to be put into the PolledDataReturned Subroutine for the modified control.
It needs to replace the existing code between the "Try" and the "Catch" statements.
Another important point is that the"0" bit is the least significant bit and the "15" bit is the most significant.

Thanks again for a new feature in the works and a preliminary peek at it.