# Mobile Client

**URL:** <https://forum.inductiveautomation.com/t/mobile-client/4185>\
**Category:** Ignition\
**Created:** [March 21, 2012, 11:15pm UTC](https://forum.inductiveautomation.com/t/mobile-client/4185 "2012-03-21T23:15:12Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![DarrenAsh](https://avatars.discourse-cdn.com/v4/letter/d/779978/32.png) [@DarrenAsh](https://forum.inductiveautomation.com/u/DarrenAsh)\
**Post date:** [March 21, 2012, 11:15pm UTC](https://forum.inductiveautomation.com/t/mobile-client/4185/1 "2012-03-21T23:15:12Z")

</div>

This may sound like dumb questions, but I have a customer that wants to use a mobile client for a setup application that concerns me. What does Ignition do to prevent “stuck” bit issues if a mobile client drops a connection. The way they currently address this issue on the current platform is that the client, to jog a motor increments a register continuously when a button is held down so that if the client looses connection the register stops incrementing and the jog stops. With the Mobile Client, the way I understand it, if we did this with a script that still would not matter since the script would be running on the server, so a stuck bit would never be detected, unless IA has some watchdog timers going on behind the scenes that would kill the process.

Anyway, don’t know if this is clear what I am asking for, but could someone jump in and state is there a way to implement the current functionality for the equivalent level of validation that they now have.

Thanks,

Darren

---

<div class="post-metadata">

**Author:** ![Carl.Gould](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/carl.gould/32/7262_2.png) [@Carl.Gould](https://forum.inductiveautomation.com/u/Carl.Gould)\
**Post date:** [May 9, 2012, 8:39pm UTC](https://forum.inductiveautomation.com/t/mobile-client/4185/2 "2012-05-09T20:39:19Z")

</div>

You’re right to be concerned.

Let’s say you’re using the momentary button. It’ll write to a bit, and clear it when released. But if the connection is dropped, the client may never get the release event, or the mouse-up event.

I strongly suggest you implement timeout logic in the PLC to be safe. Or have them repeatedly hit a button that moves it in small increments.

The architecture of the mobile module is just too loosely coupled to pretend that it is a legitimate replacement for a hard-wired physical push-button (which is what you’re doing when you implement a jog control like this).

---

<div class="post-metadata">

**Author:** ![DarrenAsh](https://avatars.discourse-cdn.com/v4/letter/d/779978/32.png) [@DarrenAsh](https://forum.inductiveautomation.com/u/DarrenAsh)\
**Post date:** [June 6, 2012, 3:14pm UTC](https://forum.inductiveautomation.com/t/mobile-client/4185/3 "2012-06-06T15:14:24Z")

</div>

Just noticed there is a reply. What is currently done is the mobile client increments an integer. When that stops occurring, the motion stops.