Javier Camusso Posted February 13, 2017 Report Posted February 13, 2017 Hi everyone! I´m using the four sockets in a Vision 130, and I need more! So, I tried to redifine a socket in run time according to some conditions, but I find out that once the socket was defined, I can´t redefine it. The socket is first initialized as TCP / Port 502 / Server. A Modbus IP configuration is attached to this socket, and running as Modbus IP Slave. Then, I close the socket... ...and redefine it as UDP The result is that the socket never loose the Modbus definition, and can´t connect via UDP. When the second socket definition is executed, the socket state goes from 20 to 34. If I insert a reset of the PLC before the second definition, all runs correctly. So, I think that the only way to "release" the socket definition is restarting the PLC. Is this right? Or (more likely) I am doing something wrong? Thank you very much!!
MVP 2023 Flex727 Posted February 13, 2017 MVP 2023 Report Posted February 13, 2017 I've done this many times. All you need to do is Close the Socket, re-execute the MODBUS IP Configuration with the new attributes, then re-connect the Socket with the new attributes. I've never had any problem as long as I allow the few seconds if takes perform all the tasks. There is no need to restart the PLC. Edit: I see you're actually redefining the Protocol also. I've never tried that, but I suspect re-initializing the Socket and re-executing the Configuration block should work. The guys at support@unitronics.com should be able to give you a definitive answer on this.
MVP 2023 Ausman Posted February 14, 2017 MVP 2023 Report Posted February 14, 2017 Flex says: "allow the few seconds" and I think this is your error. Either implement the stages via timers, or create an incremental counter using compares that does the same thing triggering actions a few seconds apart. You could even perhaps use a drum sequencer for this, but as it's not many steps it's a tossup as to the mechanics of how you do it. Edit: Forgot to add that it looks like you are doing the close and init in the same scan, which is the likely main cause. I'd trial my "seconds apart" method first, then work backwards. Load up the buffer to your maximum and find the shortest time possible for your system, for what I suggest, that works reliably. Pls let us know how you go. cheers, Aus
Javier Camusso Posted February 14, 2017 Author Report Posted February 14, 2017 Flex: Thanks for your answer! Going a little deeper, the application normaly uses this socket for modbus comm as slave. In some conditions, I need to use this socket for a time synchronization. For this second use, I need the connection as UDP, and don´t have any modbus config to define. All I can do is stop the modbus listener rung... ...close the socket... ...and initialize as UDP.
Javier Camusso Posted February 14, 2017 Author Report Posted February 14, 2017 Aus: Thanks for your answer! You are right on this. I normally play with instruction orders, or I use a label to go to end of ladder when launching or modifying a connection. The PLC executes the communications at the end of ladder scan. So, I force it to do this before evaluating any connection condition. In this case, I am in test stage, so I´m using manual flags to run any single rung. This assures to avoid any timing trouble.
Javier Camusso Posted February 14, 2017 Author Report Posted February 14, 2017 SOOLVED!!! Looking to the problem, I've tried to set the protocol type manually, and YES! It works! After initializing the socket, I set the socket protocol manually in 0. Starts the synchronization, and it works. There is no need to close the socket. I think that closing the socket only got effect on TCP MASTER connections. If you are interested, you can find the details attached. Thanks everyone! Solved.pdf 1
MVP 2023 Flex727 Posted February 14, 2017 MVP 2023 Report Posted February 14, 2017 When you say set it manually, do you mean that you stored the value of zero in SI 143? I'll say this, I'm impressed with your perseverance and troubleshooting skills. Thanks for returning to the forum with a solution.
Javier Camusso Posted February 14, 2017 Author Report Posted February 14, 2017 Yes Flex, The solution is as simple as this: 1
Isakovic Posted October 24, 2017 Report Posted October 24, 2017 Hello, I'll revive this topic because I ran into a similar problem and seek advice. Does anyone know what are the codes for socket states? I also have to reuse a socket but protocol remain the same (0=PC applincation). Socket 3 at the beginning is TCP / Port 20259 / Server, then, at 4 o'clock every night, initialized to UDP / Port 123 to update the time and after that reinitialized back to TCP. It works fine for the first time (after PLC restart), but every try after is unsuccessful. Socket 3 state is 34 and there's no explanation in help files about socket states that I could find. When RFC function runs, Tx counter increments by 1, Rx remains the same for Socket 3. Other controllers that have UDP port dedicated for this purpose (no init block after startup) don't experience this problem. I'll fiddle with troubleshooting some more to find a workaround if possible in the meantime.
Isakovic Posted October 26, 2017 Report Posted October 26, 2017 This is what I found: It will work normally as long as no TCP connections take place on Socket 3, like accessing from VisiLogic or Remote Operator. As soon as PC connects at least once it will not work until PLC restarts. It doesn't matter if PC-PLC connection disconnects normally or it is violently broken. I don't know how to clear whatever PLC set in its memory. I tried closing the socket and then initializing it to other TCP and even this Modbus workaround Javier did but it doesn't work.
MVP 2023 Ausman Posted October 26, 2017 MVP 2023 Report Posted October 26, 2017 Hi Isakovic, I'm wondering SB167 & particularly SB168 might be affecting this, and also whether one can manipulate them repeatedly? I only ever set 168 at power up...have never played with altering it during running. cheers, Aus
Isakovic Posted October 27, 2017 Report Posted October 27, 2017 Hello Aus, I also set SB168 at power up, I tried messing with system bits but that didn't work. What I found to work is next sequence: - Init Socket 3 to TCP master (port as before 20259) - Delay 2 seconds - TCP connect on Socket 3 to timekeeper Server on port 123 - Delay 2 seconds - Init Socket 3 to UDP, port 123 - Delay 2 seconds - Whole update sequence - After 1 minute Init block to restore Socket 3 to original settings I don't know why it works, but it works. Hope this helps someone.
MVP 2023 Ausman Posted October 27, 2017 MVP 2023 Report Posted October 27, 2017 16 hours ago, Isakovic said: Hope this helps someone. I'm sure it will. Thanks for the solution. If it works and ain't broken, don't touch it! cheers, Aus
MVP 2023 Joe Tauser Posted October 28, 2017 MVP 2023 Report Posted October 28, 2017 19 hours ago, Isakovic said: - Init Socket 3 to TCP master (port as before 20259) - Delay 2 seconds - TCP connect on Socket 3 to timekeeper Server on port 123 - Delay 2 seconds - Init Socket 3 to UDP, port 123 - Delay 2 seconds I didn't remember (my brain plate is slippery sometimes these days) but we found a similar solution switching a port between Modbus Master and Slave using the same socket. The key is to insert timers between Socket commands to let the system catch it's breath. We found 0.5 seconds works OK. Good job! Joe T.
MVP 2023 Flex727 Posted October 28, 2017 MVP 2023 Report Posted October 28, 2017 12 hours ago, Joe Tauser said: ...to let the system catch it's breath. PLCs hate being anthropomorphized!
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now