Topics

1

Support Questions / Ver 3.8 Driver / Control Split

« on: November 06, 2014, 02:43:32 PM »

I am not sure this qualifies as a bug or is as intended but wanted to make sure you are aware.

I noticed that MfgControl.AdvancedHMI.Drivers.dll  in the AdvancedHMIDrivers project requires dlls in the new AdvancedHMIControls project.

MfgControl.AdvancedHMI.Drivers.dll needs not only MfgControl.AdvancedHMI.Controls.dll but also needs the AdvancedHMIControls project dll.

The AdvancedHMIControls project has references to the AdvancedHMIDrivers project indicating AdvancedHMIControls depends on AdvancedHMIDrivers

The AdvancedHMIDrivers project does not have references to the AdvancedHMIControls project leading one to believe that AdvancedHMIDrivers would stand alone (as before)

I usually only update the drivers in my application when a new version comes out so now it appears that AdvancedHMIControls and AdvancedHMIDrivers will need to be updated together.

I am not sure if that was your intent.  This was a bit confusing for me and this kind of circular reference may be confusing or cause problems in the future.

2

Open Discussion / Send que full, may have lost connection or data request too fast.

« on: May 16, 2014, 07:18:49 PM »

I am writing a list of tags (a Recipe) sequentially with .Write to a ControlLogix PLC.  I often get the error "Send que full, may have lost connection or data request too fast."  If I get this error I wait a while and then resend the tag that created the error and the subsequent tags.  Unfortunately it appears that occasionally some data is still not making it to the plc.  Is there a way to know ahead of time if the que is full and avoid the error altogether?

3

Open Discussion / Advanced HMI tested on Control Logix L7 or L7S processors

« on: May 08, 2014, 01:23:34 PM »

I have successfully used AHMI with L6 series CPU programmed with RSLogix 5000.  I was looking at the L7 series and noted they are programmed with Studio 5000.
Has anyone tested AHMI with the L7 series?  Also has anyone used it with the safety plc versions L6xS or L7xS?

4

Support Questions / Cannot read non zero indexed Bool array in EthernetIPforCLXCom V 3.61

« on: December 05, 2013, 02:26:18 PM »

  .Read(HMIBOOL[0],1) works but .Read(HMIBOOL[1],1) (and any non zero index)  does not.  I thought this was working on one of the previous versions, but it does not on V3.61 and returns an unhandled exception.

Until now I have always been reading the entire array starting at index 0, but my Bool array has grown and I recently found a read of a large Bool array will only return 2080 bits. ( I have a big machine with a lot of alarm bits) What I thought would be an easy workaround with .Read(HMIBOOL[2080],N)  isn't going to work.  There are other ways for me to work around this,- but if you can and are going to fix these issues, please let me know.  Thanks

5

Support Questions / Bool Array size read limit in EthernetIPforCLXCom

« on: December 02, 2013, 07:44:55 PM »

I am trying to read a Bool array with 2247 elements.  However the returned array from a read is only 2080 elements long.  Is this an arbitrary limitation that can be changed in the next version?  Or is it a fundamental constraint that I will have to work around?

6

Support Questions / Tag Type in EthernetIPforCLXCom

« on: November 27, 2013, 06:18:02 PM »

Is it possible to query the tag type in the EthernetIPforCLXCom driver?
For example lets say I have a list of Analog tag names and I need to know if they are a DINT or REAL in the PLC.
Unfortunately many of the tags are part of a UDT, so the tag doesn't show up if I use GetTagList.  If they were not part of a UDT, GetTagList / AbbreviatedType would tell me what I want to know.  Ideally there would be a function that I could pass a single tag name and it would return the tag type.  Does such a function exist?

By the way, ver 3.61 is working really well, I haven't found any problems with it.  Good work.

7

Support Questions / 3.59 Bugs

« on: October 07, 2013, 07:08:44 PM »

In CLX driver:

A SINT with value 127 or any negative number cannot be read in Version 3.59

On Ver. 3.58 the PLC value would always be returned as a byte instead of signed byte, but Ver 3.59 throws an exception.
I used the following workaround on 3.58:
reads:
                Dim bytA As Byte
                For i = 0 To N - 1
                    bytA = CByte(S(i))
                    If (bytA < 128) Then
                        S(i) = CStr(bytA)
                    Else
                        S(i) = CStr(bytA - 256)
                    End If
                Next

writes:
If V < 0 Then V = V + 256   '(before writing to PLC)
 
On Ver 3.58 an empty string could not be written to the PLC, however if the PLC string was empty it could be read.
On Ver. 3.59 an empty string can be written to the PLC, but the last value before the string became empty in the PLC is always read back after that.

I have also noticed it is possible to read a LINT but not write a LINT.
a LINT is a bit odd and not used much, but thought I would mention this in case it can be fixed.

8

Support Questions / EthernetIPforCLXCom.vb ComErrorHandler Responded(e.TransactionNumber)

« on: August 16, 2013, 12:03:06 PM »

There is a problem with EthernetIPforCLXCom.vb ComErrorHandler
Responded(e.TransactionNumber) (2nd line)

e.TransactionNumber is a UShort but Responded is only dimensioned to 255
Several times now my program has stopped (in the VB2010 Express IDE with standard error handler settings) at Responded(e.TransactionNumber) because e.TransactionNumber > 255.  So there may be 2 issues, one with the out of bounds and the other with the failure of error handling to kick this error back to a real error handler.

Some other less important issues:

With a 1756-L61 and 1756-ENBT/A I keep getting many Open Errors (after last night 45000) as reported by the PLC web page Diagnostic overview.

This is what I am doing:


 PLC.REAL_N = 1560
 PLC.DINT_N = 1000)

             frmLoad.EthernetIPforCLXCom1.Write("HMI.TRIGGER", 1)
            Thread.Sleep(150)

            sHMI_REAL = frmLoad.EthernetIPforCLXCom1.Read("HMI.REAL", PLC.REAL_N)

            sHMI_DINT = frmLoad.EthernetIPforCLXCom1.Read("HMI.DINT", PLC.DINT_N)



It seems to work OK, but the Open Errors don't give me a lot of confidence.

I am running this once a second.  I am a bit surprised at the high PC CPU usage this requires during the read, but it does work.
It takes about 200 msec for the reads.

I have also found that a Read of a Bool array doesn't work.  I don't know if this hasn't been implemented or is a bug.

When you put out the next version, it would make me more confident if it didn't have any compiler warnings.

Keep up the great work.  This is a really cool project.