Wait on Front Panel Activity crashes labview?

[johntrich1971]

---

@msoflaherty wrote:

Good suggestion john, but delegating actions to a parallel loop is indeed what happens. Most of the events the system performs, though, are commands to set and monitor a very slow serial system, which can only be working on one thing at a time. If the user tries to change a setpoint, it has to wait for the background read to complete before that action can begin - even though it's in a different parallel loop. Events that don't use the same resources are plenty responsive.

---

Instead of locking out the front panel why not just lock out the controls which would need the desired resources. Also, does the background update really have to be at 1 second intervals? Could that interval be made a bit longer? Are you transmitting a lot of data over the serial port? Maybe there are ways to speed up the protocol on the serial port, but it's hard to know without seeing that code. 

[msoflaherty]

The front panel isn't 'locked up', but any requested actions by the user won't happen for an increasingly long delay.

For example, let's say they try to write a setpoint, but a background read is happening. That read needs to finish before it can start executing the write. To the user, this looks like a slow response. If they try changing another setpoint in the meantime, that will get queued, but it'll have to wait for the background read, and then the first write. The front panel doesn't 'lock' at all - they can still interact with other controls and resources, but those setpoints won't update any quicker, and unfortunately there's nothing that can be done about that

Speeding up the serial communications would be fabulous, but unfortunately it's *incredibly* old hardware, and just comes down to not being able to process read/writes any faster. It's a piddling amount of data, and we're very far from the 9600kpbs baud limit, but still the data trickles out.

Adjusting the timeout is certainly an option, but increasing it decreases the monitoring rate when no user  is active, so there's a balance to be made. I would adjust the timeout based on user interaction if i could, but given that it's the same events for both user and programmatic event handling, there's no easy way to change it without selecting on the source in each event, which is a lot of work. That's the underlying flaw, really - not being able to separate user events from programmatic ones. I should've had an event structure just to handle UI events, and have those events trigger another event structure to perform the action separately. Then tracking FP activity would've been straightforward. Certainly something I'll bear in mind for next time.

[msoflaherty]

my last reply got flagged as spam(?) and is waiting a moderator's approval.

to try again, the FP isn't locking - it's simply that the device being communicated with can't process the request. The underlying hardware is some truly ancient devices that are very, very slow - no way to speed them up, unfortunately.

So, if a user requests a setpoint write, it'll get queued immediately, but has to wait for the background read to finish. If they request another write, that has to wait for the background read and previous write... hence, it *appears* sluggish, even though it's working it's little socks off. But if the user waits patiently without clicking anything, the timeout event will nip in and stick a background read in the queue pretty quickly once it's done, often getting in there before the user.

Increasing the timeout would work, but it reduces the background monitoring rate (which is already bad, given the slow hardware) so it's a balance.

[johntrich1971]

I still suspect that the communication with your hardware may be able to be improved. If you could share what the hardware is and your communications code perhaps there is someone here who has had experience with that hardware and has some pointers on how to communicate efficiently with it.

If you have to live with the "sluggish" UI there are a few things you can do to make the user experience better. First, I would put an indicator on the screen that shows that lights up when the instrument is busy. This is a visual cue to the user to wait. I might also disable and grey out the "sluggish" controls if the backlog gets too large ("too large" would be an arbitrary number that you would define) and then return the functionality when the backlog gets worked down. This is an additional cue to the user that they have to wait before sending any other commands.

[BertMcMahan]

This doesn't fix your original issue of Wait for Front Panel Activity, but it might help as a workaround. "Set busy.vi" and "Unset busy.vi" can change the mouse cursor to the Windows "I'm busy" swirling cursor which can help indicate to the user that it's working on something.

I'd also suspect there are some inefficiencies with your device comms code. Having a serial read take multiple seconds means there is a delay happening somewhere. 2 seconds of delay at 9600 baud is nearly 2000 bytes of data. Of course, if it's on the instrument side there's nothing you can do about it.

My hunch is that each transmission is using a "timed out" approach, where there's some data sent, then a small timeout, then Bytes at Port is used to acquire the whole port. If you could switch to termchars then you could get a couple orders of magnitude more speed out of this thing.

I agree with johntrich1971- is there any way you could post your instrument model and communication code for us to look at? I can't fix your Wait on Front Panel Activity issue but I might be able to help with serial comms.

[msoflaherty]

I appreciate the interest, but I must admit this is veering a little off-topic, and isn't really a problem I'm looking to solve. Still, for interest, and just in case, here's some details:

The device in question is a CAEN SY527 - an old high voltage power supply system whose age I can't date. Communications can be achieved via a proprietary CAENNET interface (for which we don't have the necessary hardware) or standard RS232, with a maximum 9600 baud. The serial interface is a VT100 - an interface intended very much for human-driven interaction, not programmatic control. Automating functionality has been a nightmare, and I've spent plenty of weeks on it already, with no intention to rework it at this point!

Bert's hunch is correct; I use a timeout approach for reading from the serial port until no further characters are returned within a given period, assuming this to be the end of the transmission. I would love to implement a termination character based approach instead, but the device doesn't support it.

The VT100 interface maintains a character matrix that needs to be parsed to obtain the required information. Strings arrive over the serial port, with a collection of commands such as "move cursor to position X,Y. Clear line. 1243. Store current cursor position. Move to position X2,Y2. Bold font. Highlight. V0. Restore previous cursor position. 240"
(with those commands being represented by escape sequences).

Since I'm trying to turn this into a Command -> Response format, I go about all the swings and roundabouts needed to navigate to the required "display", "page", "subpage" and row/column (through a series of serial writes that depend on your current location), until I arrive at the correct point on which to "type" my new setpoint.
The device will then continue to stream output (it's _always_ streaming output, intermittently, to keep the display up to date), and at some point I need to decide to parse that character matrix and determine if my request succeeded.

Hopefully it's clear that I should only try to parse that character matrix at such a time that I know (or, hope, as i have no way of _knowing_) it's going to be in a coherent state.

Data transmission is patchy (a few bytes interspersed by silences), and random un-requested updates are interspersed with screen updates relating to the command in question, so i can't tell exactly _when_ that'll be. I just wait until it's quiet, and hope.

That wait can't be too short, because some commands (switching groups, for example) invoke some *long* silence periods during screen re-write.

All said and done, I really can't see any way to speed up the communications with the device itself. The screen re-draw is slow not just in LabVIEW, but also in hyperterminal, which I assume runs as fast as any interface can be expected to. I then have additional delays on top of that due to the need to only evaluate the matrix in consistent states.
(apologies for not posting code, i'm working another job right now and stretched for time, but it's very conventional, other than being very messy)

[msoflaherty]

Regarding the UI experience, I do have an indicator of activity. Disabling some controls while it's busy is an option, but it doesn't really do very much more, they can tell what the current state is. Triggering background reads, though, explicitly loads the system and slows things down a lot for the user, so preventing those while a user is working is really the only thing that will help. Doing it is easy - turning it back on if the user forgets is merely my issue.

So far, altenbach's suggestion has yet to crash, so fingers crossed.

[BertMcMahan]

Dang- that sounds like a pain in the butt to write for. Thanks for the explanation and good luck.

[Ben]

---

@msoflaherty wrote:

... here's some details:

The device in question is a CAEN SY527 - an old high voltage power supply system whose age I can't date. Communications can be achieved via a proprietary CAENNET interface (for which we don't have the necessary hardware) or standard RS232, with a maximum 9600 baud. The serial interface is a VT100 - an interface intended very much for human-driven interaction, not programmatic control. Automating functionality has been a nightmare, and I've spent plenty of weeks on it already, with no intention to rework it at this point!

Bert's hunch is correct; I use a timeout approach for reading from the serial port until no further characters are returned within a given period, assuming this to be the end of the transmission. I would love to implement a termination character based approach instead, but the device doesn't support it.

The VT100 interface maintains a character matrix that needs to be parsed to obtain the required information. Strings arrive over the serial port, with a collection of commands such as "move cursor to position X,Y. Clear line. 1243. Store current cursor position. Move to position X2,Y2. Bold font. Highlight. V0. Restore previous cursor position. 240"
(with those commands being represented by escape sequences).

Since I'm trying to turn this into a Command -> Response format, I go about all the swings and roundabouts needed to navigate to the required "display", "page", "subpage" and row/column (through a series of serial writes that depend on your current location), until I arrive at the correct point on which to "type" my new setpoint.
The device will then continue to stream output (it's _always_ streaming output, intermittently, to keep the display up to date), and at some point I need to decide to parse that character matrix and determine if my request succeeded.

Hopefully it's clear that I should only try to parse that character matrix at such a time that I know (or, hope, as i have no way of _knowing_) it's going to be in a coherent state.

Data transmission is patchy (a few bytes interspersed by silences), and random un-requested updates are interspersed with screen updates relating to the command in question, so i can't tell exactly _when_ that'll be. I just wait until it's quiet, and hope.

That wait can't be too short, because some commands (switching groups, for example) invoke some *long* silence periods during screen re-write.

All said and done, I really can't see any way to speed up the communications with the device itself. The screen re-draw is slow not just in LabVIEW, but also in hyperterminal, which I assume runs as fast as any interface can be expected to. I then have additional delays on top of that due to the need to only evaluate the matrix in consistent states.
(apologies for not posting code, i'm working another job right now and stretched for time, but it's very conventional, other than being very messy)

---

VT 100's could talk at 19.2K

Spoiler

I have one in garage if you want purchase a spare. 

😋

Hyper terminal was written to support VT 100 at the very least so if in a pinch you could fire up hyperterminal and use it instead of the VT 100 to rule out a hardware issue like the serial port spraying garbage.

Did I read a post that indicated the entire PC was crashing?

If so I suggest you start whacking away parts of the application to determine what part is invoking the crashing.

Modern OS do not rash due to a software issue but old OS could. Are you getting blue screen of death?

Ben

[msoflaherty]

Hi Ben.

You know what, you're right and I've been talking rubbish about the 9600 baud rate - it is configured for 19200. Nonetheless, it's configured as fast as it can go, whatever that number may be. Often users do switch to hyperterminal for a more responsive experience (primarily since it doesn't need to wait for a complete transmission to arrive before parsing it - that's done implicitly by the human), but that of course disconnects it from the LabVIEW monitoring, which isn't ideal (and then i rely on them starting it back up again).

The crashes do take down the OS - windows 7 system event logs are all normal one minute, then there's a 'system powered up' message, and warnings that the previous reboot was unexpected. The salient part seems to be 'system rebooted due to bug check 0x000000d1'. If I had the time I would get all the BSOD debugging tools and analyse the memory dump, but it seems like a bit of a faff, and I can't imagine it will be of much use in solving things. Sorry, not being much of a community contributor, but right now i just don't have the time. 

>I suggest you start whacking away parts of the application to determine what part is invoking the crashing.

Adding the 'Wait on User FP' snippet in the first post was a small and isolated change to a system that's been stable for a long time now, and correlates very well with the issue arising, so it really looks like that's where the problem lies.