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 - jsorah

Pages: [1]
1
Thanks for the tips, I got the read working with some fairly simple changes. 

In case it may be useful to anyone else -

Added this function to AllenBradleyPCCC.vb
Code: [Select]
    '* Word range read
    '* Reference : Page 7-34
    '* Supported by PLC-3 and PLC-5 only.
    Public Function WordRangeRead(ByVal byteSize As Byte, ByVal address As MfgControl.AdvancedHMI.Drivers.PCCCAddress, ByVal TNS As Integer) As Integer

        Dim pck As New MfgControl.AdvancedHMI.Drivers.PCCCCommandPacket()
        pck.Command = &HF
        pck.FunctionCode = &H1
        pck.TransactionNumber = TNS

        'This is basically what happened in version 397e, except the command, function and TNS were manually packed.
        For Each val As Byte In address.ByteStream
            pck.EncapsulatedData.Add(val)
        Next

        SendPacket(pck, TNS)
        Return TNS
    End Function


And replaced code between lines 1772 - 1783 in AllenBradleySLCMicro.vb with this

Code: [Select]
                '* A PLC specifies the number of bytes at the end of the stream
                If MfgControl.AdvancedHMI.Drivers.PCCCAddress.IsPLC5(ProcessorType) Then
                    PAddress.ByteStream(PAddress.ByteStream.Length - 1) = CByte(NumberOfBytesToRead)
                    WordRangeRead(Convert.ToByte(NumberOfBytesToRead), PAddress, TNS)

                Else
                    PAddress.ByteStream(0) = CByte(NumberOfBytesToRead)
                    ProtectedTypeLogicalRead(Convert.ToByte(NumberOfBytesToRead), Convert.ToByte(PAddress.FileNumber), Convert.ToByte(PAddress.FileType), _
                                               Convert.ToByte(PAddress.Element), Convert.ToByte(PAddress.SubElement), TNS)
                End If

               

2
Thanks for the response Archie.

Is it possible that someone (i.e. myself) could write a driver to support PLC5 on the newest version or would that require modification of the MfgControl.AdvancedHMI.Drivers binary provided in the project?

3
I am currently unable to read values from a PLC-5 via Ethernet - using the EthernetIPforPLCSLCMicroCom driver.

The error is a -20 (no data returned/no response), but I haven't looked too deeply at what's going on myself.  My program works and reads values from the PLC-5 without issue when reverted to v397f (with a ControlLogix patch).

A few sample tags I'm trying to read in case that is useful:

N7:101
O:033/1
B13:8/13

4
I've recently (as of 2/6/2015) had some connectivity issues going on between me and one of our PLC's.  For some reason my workstation is closing the connection (->FIN,ACK/<- ACK/<-RST,ACK) and then the CIP driver attempts to reestablish a connection via another Forward Open, but the program starts throwing an index out of bounds exception. I used a decompiler to step through and figure out where this exception was happening - from what I could tell the transaction number is being used without the 0xFF bitmask in a few array lookups in the ForwardOpen method of the CIP class.  Not sure if changing that would help much on my end, but I figured I would add the observation to this thread.

Figured out that it is AdvancedHMI closing the connection because some packets were taking longer than the specified timeout (timeout of 500ms in the patch in this thread, packets were taking between 700ms to 1000ms on occasion).  The latency seems to have gone away for now and no more issues, but given the sporadic nature of it I suspect it could come back in the future and give me more trouble.

Is there a possibility the timeout in the EIP driver could some how be made configurable in a future version?

5
I've recently (as of 2/6/2015) had some connectivity issues going on between me and one of our PLC's.  For some reason my workstation is closing the connection (->FIN,ACK/<- ACK/<-RST,ACK) and then the CIP driver attempts to reestablish a connection via another Forward Open, but the program starts throwing an index out of bounds exception. I used a decompiler to step through and figure out where this exception was happening - from what I could tell the transaction number is being used without the 0xFF bitmask in a few array lookups in the ForwardOpen method of the CIP class.  Not sure if changing that would help much on my end, but I figured I would add the observation to this thread.

6
Open Discussion / Re: Advanced HMI on Linux?
« on: January 29, 2015, 05:24:16 PM »
Archie, did you have to do any soft links to DLL's in your solution when using mono?

I was having issues (Incomplete Solution error) running my project until I executed this in either the AdvancedHMI/bin/Debug or AdvancedHMI/bin/Release directory on the linux machine:

Code: [Select]
ln -s MfgControl.AdvancedHMI.Controls.dll ".\\Mfgcontrol.AdvancedHMI.controls.dll"
ln -s AdvancedHMIControls.dll ".\\AdvancedHMIControls.dll"


** I also want to note this is on CentOS 7 **

7
Support Questions / Re: EthernetIPforCLXCom1 "Invalid Tag"
« on: January 29, 2015, 02:04:10 PM »
The most recent patch appears to have resolved the problem, thanks Archie.

8
Thanks for the quick response.  I'll continue to follow up with the issue in that thread.

9
Support Questions / Re: EthernetIPforCLXCom1 "Invalid Tag"
« on: January 29, 2015, 09:08:01 AM »
Applied the patched dll and I am still getting the same error as before, but the packets no longer display as malformed in wireshark.

10
The tag I am trying to read is as follows (using the Read function on the ControlLogix driver class):

Program:MainProgram.AnalogInSlot3.Ch0InputError

Exception received in 397e


MfgControl.AdvancedHMI.Drivers.Common.PLCDriverException: Read Failed. Invalid Tag Address.,  Status Code=4
   at AdvancedHMIDrivers.EthernetIPforCLXCom.Read(String startAddress, Int32 numberOfElements) in \AdvancedHMIDrivers\AllenBradley\EthernetIPforCLXCom.vb:line 388


I did a wireshark trace and notice that the CIP packets sent with this tag show malformed in the Info column and the tag sent to the PLC itself is different from 397d.

Reading this tag works with the 397d code and the CIP packets do not show up as malformed.


Pages: [1]