Mobile Client screen turns black

I have seen quite a few issues with Mobile Clients, but I just don’t know what to think of this one. First I am running 7.9.5, I was unable to find any warnings or errors related to or even unrelated to the client in the logs. Usually when a Mobile Client loses it’s network connection the screen turns white and you are presented with the oval reconnect button in the center of the screen, but that was not the case. I found the 2 test subjects with full wifi bars and black screens. Usually if someone terminates a client it closes out completely. These clients turn their screens black every 12 hours or so and the Gateway status page says they have been terminated, however the iPad still thinks their is something running because it is holding a place for them. When you triple click the home button it shows the Mobile Client as one of the apps running. In fact if you select it sometimes it will start working again. I’m befuddled and would appreciate some clues if anyone has any.

If you have a newer IPad , it looks like safari is blocking Java applets. If you enable developer options there is a workaround

I don’t believe that is the issue. Mobile Clients don’t run locally on the device. They are like a virtual session and run on the Gateway unlike the other Ignition clients. Most mobile devices don’t have the ability to run a JRE at the moment.

Ok Here is an update. It seems that it is only effecting one of the clients.

I should rephrase that. Only one of the mobile projects.

OK I finally caught it failing with it set to debug mode. It logged:

ClientVM 19Feb2018 23:11:58 Client vm 72c23f55-704d-7a28-f7fd-c374ecc85521 closed: Session invalidated

Any ideas what I should be checking for? How does it get invalidated? Is this because it timed out too many times?

So we had Zabbix Ping the PLC in question every minute last night. The Mobile client still lost its session, however our monitoring system never lost it’s contact with the PLC. So I assume that means for some reason Ignition is the culprit? Then Why are none of the other Mobile Clients effected?

And here was the error log from last nights event:

Error communicating with Gateway. Read timed out
at Method)

That often means some part of that project is hammering the gateway occasionally, possibly with an unusually long-running query. Or some event has an infinite loop (one event makes a change triggering another event, which triggers the first again, etc).

1 Like

I went and checked through the tags, the code on this one is very simply write tag after write tag function. I found I was using the default scan class. Lazy of me, so I changed my scan class. Don’t know if it will help but it is the magic sauce I use in a lot of other spots. The question I had regards something you said. I didn’t find any silver bullets, but there is one tag that is a status tag for the entire project. I noticed that by design I was forced to call it for nearly every component. Do you think this may be my issue? Then if it is, how do I get around it because I am not the one programming the PLC?

I don’t get it. Gateway tags have scan classes, and run in the gateway, so are unaffected by client timeouts. Client tags don’t use scan classes, but are instead change driven like bindings. If you are firing many client tag writes which trigger others, then others, then any of the earlier ones, you have infinite loops.
I can’t see what your scripts are doing, but if you are trying to run a sequencer for a PLC from a client, you might be doing it wrong. (As in, sequencers should be run in the gateway, like SFCs.)

your scan class can effect you IE setting a timeout of 5000ms. way too short. I like to set my scan classes to use a timeout of 20000ms. The Ignition default is 10000ms anyway moot point I’m not a great communicator just trying to give you all the details. It probably wasn’t relevant. the status tag was, I believe. This situation is so bizarre I am grabbing at any hint I can find. I would even ignore it if it wasn’t consistent enough to bother the customer.

Thanks for helping by the way I appreciate you offering your experience

My next experiment in my quest for resolution: I ran the problematic Mobile project in a browser on my computer example:
Unlike the mobile devices my computer is hardwired into the network. This client instance has not had it’s session revoked while the mobile device already has twice. I’m not sure how this helps me since I had two mobile device instances running using completely separate AP exhibiting the same issue.

This is a good test, but is not definitive. Regular PCs have substantially different multitasking, and usually a lot more computing horsepower. If your project has pathological scripting loads, a PC is much more likely to tolerate it than a mobile device. This is particularly true when the mobile device is sitting idle and its power-saving techniques are kicking in.

Good point, but it proved something to us when there was not a single failure. we purchased a surface mount 10" ELO touch screen and wedged a 4"x4" NUC in the box and called it a day.

1 Like

Still irks me but I have to move on.