Jump to content

Isakovic

Privileged Member
  • Posts

    192
  • Joined

  • Last visited

  • Days Won

    13

Posts posted by Isakovic

  1. On 10/23/2018 at 12:14 PM, Ausman said:

    Perhaps there is a collision happening that you aren't aware of as it isn't on all the time, and these tests might show it up.

    I've seen this once. Connection was breaking because there was a card reader on the network with the same IP address.

    What does "socket state 34" mean in your picture, I can't find it in help files?

    If you already tried with keep alive registers, maybe try the next sequence:
    When SB148 goes down (or some other condition that recognizes Ethernet problem) call socket close block, then delay, than initialize socket to UDP, then delay, then initialize it back to TCP. This resurrects blocked socket in my experience, maybe (probably) there's a more elegant solution.

    Are there any other client applications besides you accessing via VisiLogic?

  2. On 8/14/2018 at 2:48 PM, acisre said:

    No when rung 6 is executed, this rung also resets the timer.

    True. I wasn't paying attention.

     

    11 hours ago, acisre said:

    I do have another question though: if I would leave out the timers in my program, I wonder what happens.

    I can confirm that Modbus functions can be called one after another without delay (with "Modbus in progress" bit as condition) and it works without problems. As soon as one function is called "Modbus in progress" bit is set in the next rung blocking second function from being called before first one is finished.

    Maybe if you called subroutine with CAN write functions after each of those rungs in the picture you first posted, it could work without timers. Although, I don't know if it would make any difference.

  3. No problem Johschr, glad to help.

    You could see what is stored in MI900 and following registers by opening block "SD Utility Delimited Line". There you will see data that is written. It will be couple of rows of what is to be written into CSV file, each row in this block will be data in consecutive columns.
    Ex.
    #1 Indirect text - ML 15 (Because you have a function block that turns date into ascii in line 1 of your code)
    #2 Indirect text - ML 10 (Because you have a function block that turns time into ascii in line 1 of your code)
    #2 Numeric field - MI0 (Maybe a process value, pressure)

    So block "SD Utility Delimited Line" will take all those fields, add delimiters on the end and store all that into one line of ascii characters starting from MI900. That's how to see what is in MI900, basically one row of your CSV file.
    It could be that MI900 quickly changes value when function is called because it first holds titles of columns until they are written in line, and then gets overwritten with process data.

    Can't really say what is causing PLC to freeze. Looks like up arrow on keyboard is used to reset status bits from one write function to allow the next one to be called, from what I can see in the pictures. Does data get written into CSV after pressing it? Maybe there is some sort of conflict if you are accessing and SD card while PLC is writing to it. Just guessing now, troubleshooting someone else's work can be difficult.

  4. MI900 is the beginning register of a line that will be written into CSV file by block "Write -> SD". So MI900 and couple of registers after it (MI901, MI902...) will contain ASCII stuff to be written, each register is 16 bits, so it will hold two 8-bit characters, it's difficult to interpret what those registers contain just by looking at them.
    Help file is useful, open every block and click help to see what it does.

    How big is that file that you are writing into? Maybe there is a limit to how large it can be. If you are writing every minute it can get big over time.

×
×
  • Create New...