Jump to content

Remote Operator Issues


dkmiller16

Recommended Posts

I am new to Unitronics and this forum, I am not a programmer, so I will try to explain my issue to the best of my abilities. I work in a woodworking facility and we have quite a few machines with many different brands of PLC's. Like I said I in no means do any programming but I have worked with them enough that I am comfortable with downloading the "program" to open up and look at and sometimes change some values within the program, only after it is deemed necessary and I have the green light from whoever did the programming. 

The issue I am having is pertaining to a PLC being used in an Outdoor Wood Boiler that we use to heat our building with. We are using a Unitronics V350-JS-TA24 PLC. So the Boiler was built and shipped to us from 6-8 hours away, we did the install of the boiler, ran a CAT6 line to the PLC which is connected to our server internally, and then had the tech login remotely and finish up all communication settings. From the start we had some issues with sending out email alerts if there were any sensor faults. We put the email issue on the back burner and decided to use the remote access app, that way we could see what was actually happening with my Boiler system. I downloaded the app for the owner here at the company I work for and also for myself, I had all the params setup to remotely view. I was able to use the remote app without any issues for a couple days and then all of a sudden I wouldn't be able to access the PLC, This has gone on for a couple weeks, we have tried to recreate the scenario and cannot do that. It seems to be completely random, as far as day, time, or usage of app. When I do have the connection issue if I go out and check the PLC, I go to "Network Status" page, it still shows the "Remote Connection" like it is still connected and clearly no one is connected. In order to clear the "Remote Connection", I need to cycle power, as soon as I do that I can connect again with no issues. 

My tech that set up the PLC keeps telling me its a firewall issue and my IT guy keeps telling me that its not a firewall issue. I have had both guys working on this remotely at the same time to try to figure out the issue and neither is able to resolve. When I am here during the day it is not a big issue but I live 20 minutes from work and I am usually making a trip to cycle power a couple times a week , whether its in the evening or on the weekend. 

Link to comment
Share on other sites

  • MVP 2023

Hi DK,

There are a number of things that might be causing this.  The very first one to try is to see if a system bit is turned on. 

Access Information mode.  To do this, "touch the touchscreen in an area that is not occupied by a Keypad Entry variable or other screen object that has been assigned a Touch Property".  Then hold the "i" button until asked for the password.  If the password is still standard, then enter 1111.  If it has been changed by the supplier, ask them for it.  (I may have this a bit wrong, please allow for me never using 350s, but the principles are the same across the range).

Once in Info mode, navigate your way to SB168 and see if it is turned on.  Please then advise back on this result.  This bit controls a "link recover" function that might be the root cause of your dropouts.  If it is off, the program needs to be changed to have it turned on at power up, and the supplier's tech can do this remotely.  In the interim, if it is off, please turn it on and see how it goes.  If you do this, be aware that any power interruption will change it back to off.

cheers,

Aus

  • Like 1
Link to comment
Share on other sites

  • MVP 2023

Don't forget my little friend SI 101 - TCP Retries Timeout (in units of 100 ms).  Set it from 2 to at least 5.  Or maybe 10.  If you ping the unit when it's not working you may be able to get a feel for response time.  Set the PLC higher than your worst case.

My son demonstrated this to me playing Call of Duty online with his Xbox.  "Dad, we need better Internet!  This sucks - the ping is really slow today."  He was running about 200 ms during a time of day when a lot of people are online.

Joe T.

  • Like 1
Link to comment
Share on other sites

I am the boiler tech for dkmiller16. 

Socket 2 in the program is setup as a slave, protocol is TCP, port is 20258.  The problem they are experiencing is that sometimes the socket does not close when they disconnect from the app.

I did change power up value of SB 168 to 1, though it appears that would only apply when the physical network link got lost?

There is one unused socket left, I guess it could be used as an alternate remote connection port.  I might do this, and make the rising pulse of SB 149 initialize the alternate socket and vice versa, this would always keep the one fresh.  Any reasons why the socket would not be closing properly?

On another note, I think we got email working properly thanks to a tip from Unitronics support.  In the past mail.com accounts worked very well for me, but its been a year or 2 since the last Vision project that needed email.  This time around the mail.com accounts were barely working at all, strangely enough it would about once every ten times.  Most times the socket would connect, SB 345(email send bit) would briefly turn on then off again, and email status would stay at 1/in progress.  Anyway, the following option has seemed to work well so far, and I have not seen anything on this forum mentioning it, so will do it here.

Create an account with https://www.smtp2go.com/.   This is just an email server, you do not have an email address with them.  You create a username and password, that are used in the Vision email setup as email authentication.  Server address is mail.smtp2go.com, various ports are available to be used.  In the "From" field in Vision email setup, you enter any email address you want to send from, can be gmail, hotmail, whatever.  The smtp2go account is free for a certain amount of emails per month. 

Thanks for all responses to these issues, and thanks for your patience Drew, it has been a pleasure working with you!

Link to comment
Share on other sites

  • MVP 2023

Hi ahoover,

Uhmmmmm.........I'm no networking guru....but....

Why are you using 3 sockets?

Am I mistaken in believing that the socket never closes and constantly talks to the router as a keep alive function?

And I don't see how the rising pulse of SB149 is going to initialise the other socket correctly, shouldn't it be falling?

Thanks for the email tips.

Always learning!  Cheers,

Aus

Link to comment
Share on other sites

  • MVP 2023

Also,  don't forget the communication settings in RemOp.  Some of my remote units need much longer timeouts than the default 1 second, and I have seen an auto reconnection happen on a 4th try on lines not as good as they should be!  Simple things to adjust if necessary.

I actually don't use RemOp at all, I prefer Remote Access.

cheers,

Aus

Link to comment
Share on other sites

I am also not the expert on networking, else I wouldn't be having these issues, right? :)  I understand you basically need a socket for each different type of network function, remote connection, email etc..  I have one socket set to TCP, server, on port 20258.  After this socket is initialized it "listens" for an incoming connection request on port 20258 from a remote client.  Another socket is set to TCP, client, on port 20256, it reaches out an makes a connection to the email server when the program needs to send an email.  The 3rd socket is set to UDP_RAW on port 20257, it is used by the DNS resolver function to resolve the email server address.

To be clear, the issue was never dropping a connection because of a time out or something the connection to seems to be plenty fast enough.  The issue was always socket 2 not closing when the remote client disconnected, though it would only happen randomly.  Interestingly, the problem only seems to occur when using the cellphone app.   My idea was to use socket 0 on port 20259 as an alternate connection channel, which I have done and tested already.  Now when when a connection is established on socket 2, the rising pulse of SB 149, initializes socket 0, if a connection is made on socket 0, the rising pulse of SB 147 initializes socket 2.  This worked well when I tested it.

Allen

Link to comment
Share on other sites

  • MVP 2023

OK Allen,

So the question at present is if the connection is still working ok since the SB168 change?  Maybe that has many intricacies for such a simple description.

For your sockets work, I am still confused as to how you're not creating a fast acting loop, and how do you then know the right connection to get in on?  I must be being dumb at present (always!!)

cheers,

Aus

Link to comment
Share on other sites

I don't believe turning on SB 168 changed anything.  

In this case socket 2(SB 149 turns on when socket 2 is connected) is listening on port 20258, socket 0 (connected = SB 147) is listening on port 20259.  So they connect on port 20258, SB 149 turns ON, they disconnect, socket 2 closes and SB 149 turns OFF.  Same for port 20259, though they usually use port 20258.  The problem is, sometimes when they close the connection from their phone app, SB 149 stays ON like somebody is still connected on port 20258.  In reality nobody is connected anymore but socket 2 did not close and can therefore not accept any new connections.  This was their problem from the beginning, and the only option they had was to get to the actual panel and re-power the PLC which in turn re-initialized socket 2.  This still happens for them occasionally, but now when socket 2 "freezes up" they change the setting in their phone app to port 20259 which allows them in on socket 0.  The magic in the program is that when they connect on socket 0/20259, SB 147 turns on which re-initializes socket 2 so it can accept connections again.  If this doesn't make sense, maybe someone else can explain it better.

I still have no idea why the sockets are not closing sometimes, though the above solution is working okay for them.  

Now email is a different story!  Twice now the PLC has gone crazy when trying to send an email, I witnessed it once when sending a test email from it.  I think it re-powered, because it disconnected my remote connection, when I was able to get back on, it seemed the ladder program was no longer running.  I could get nothing to respond anymore, and noticed some timers that were used in the program had random really high values loaded to their presets.  Nothing was sane until I completely re-loaded the program to the PLC.  At this time we have email disabled, because we can't afford to have this happening.  Am starting to think this PLC is jinxed!!

Thanks, Allen

Link to comment
Share on other sites

  • MVP 2023

Wacky timer presets is a sign the memory was corrupted.

Make sure your battery is OK, and that you have the latest OS installed.

There may be something in your collective email code that's getting out of the memory sandbox.  Are you doing Modbus TCP or talking to the PLC with a custom program in this application?  Either one of these scenarios has the ability to screw the RAM up with un-intended values.

Joe T.

Link to comment
Share on other sites

I have had the same issue with socket getting stuck open after remote operator app users do a clean disconnect. Had to keep an alternate socket and reboot PLC periodically. Most prominent case of that issue was on a V1210 with very poor quality DSL internet service. 

Item two: I have observed two V430's (different sites and unique programs) go into black screen/STOP MODE  pressumably when trying to send an email.  My substainsiation for this theory: first V430 I ever used ran  over a year with ZERO problems, the trouble began when I put it on the internet and started using email. Also have had poor reliability on success of email transmissions. 

I think I finally got the bugs out with changes in how the emails are sequenced and triggered. I had to construct logic to command the SMTP socket connect a second time if not connected after 10 seconds at one of my sites. It sends a test text message to me everyday at noon as a primative 24 hour periodical watchdog.  So far there have been no BSOD's or failed emails on the two V430's, only after a major overhaul of email trigger and socket logic. 

I beleive the frozen Sockets with remote operator app usage had NOTHING to do with firewall or ISP.  tweaked the SI's for timeouts and retries. ended up putting in unistream before i ever definatively resolved the frozen socket issue on V1210. Did have one instance where the Unistream stopped sending emails but could still be reached by VNC and online mode, meaning it had WAN connectivity but something went wrong with email sends for about two weeks. PLC reboot resolved issue. moral of the story: don't put to much faith in email to text alerts. I've thought of using a Raspberry Pi as a secondary email sender. I never get the time to,sit down and do some R&D on it. would get you SSL email capability. I have done some stand alone RPI email alerters (temperature vs. setpoint and discrete input triggers). would have to get the communication interface between PLC and RPI figured out. Hope to do some experiments with an RPI as a TCP MODBUS slave soon. 

Are you using any XB's in your code?

Link to comment
Share on other sites

At the very least it sounds like I'm not the only one experiencing these types of issues.  I could take another look at the email logic see if anything can be cleaned up.  Thought I had the perfect workaround for email encryption limitations with smtp2go.com, but now some other issues are raising their ugly heads.

Am not using any XB's, and the only TCP functions are remote connection with Unitronics apps and email.

Usually for projects requiring internet connection we use Unistream.  I'm thinking this project might be an upgrade candidate, and be the perfect opportunity to try out the new 5" unistream with built-in IO's!!

  • Like 1
Link to comment
Share on other sites

  • MVP 2023
13 hours ago, ahoover said:

from a couple VFD's.

Uh oh!!  As has been mentioned in other topics, also wondering whether your Cat 5 line and other control wiring etc is running near the VFDs and all their lines, or controls are well shielded etc.  Although UTP is in theory noise immune, I always lay it nowhere near possible problems.  Also ensure the net line run from the boiler to the switch/router avoids other lines as well. (ie isn't laid in the same conduit as the main power feed for the factory!)  I only mention this because it looks like your issue is only when comms are in action...perhaps noise is the issue.  Could possibly account for the random nature.  VFDs can create all sorts of odd issues if not done right.

And a quick edit addition:  I have found supposedly good quality patch cables to simply be straight wires, no twists at all, upon closer inspection.  Sometimes it can be worth doing one sacrifice to the cable gods to make sure.

cheers,

Aus

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...