Red Lion Background Programs

I have a very simple question: if I have a program I've written and I want it to run in the background (using an infinite loop combined with a call to sleep -- perhaps not the best solution but I'm open to suggestions), where should the original call to the program live?

A bit more detail: I'm using a Raw TCP/IP Active protocol to listen to a telnet connection set up that cycles through reporting a few temperatures. The program calls PortInput with appropriate parameters waiting for a match and updates the temperature when it gets a reply. This only needs to run every few seconds. My first solution was calling the program from the On Update field of the protocol I had set up (without a loop) but this lead to some problems.

If I'm way off the mark can someone point me in the right direction for running programs in the background? Thanks.

If you are going to run your program as an infinite loop in the background you can use either StartUp or PowerUp to start your program. To delay how often you Programs reads the Comms and Updates you can put a sleep(xxxx) command into your program

The best way to call a program that reads in raw data is to call the program from the OnUpdate field on the comms driver. This will ensure that you don't miss in coming data.

Thanks
Jeremy

Thanks for the replies!

Clay - I can't find any documententation about PowerUp or StartUp...

Jeremy - This is what I was doing at first, but it's unclear on what the "On Update" fields means. I know it sounds like it hould change when incoming information changes, but from what I can tell it is not actually doing this. The Crimson manual isn't of any help either in describing this functionality concerning comm drivers. I was debugging this it seemed like the program would run at least several times a second, when actual input is only changing every second or so. It also seemed to be hogging a bunch of resources despite there being no change in information received.

ufish235 said:

Thanks for the replies!

Clay - I can't find any documententation about PowerUp or StartUp...

Jeremy - This is what I was doing at first, but it's unclear on what the "On Update" fields means. I know it sounds like it hould change when incoming information changes, but from what I can tell it is not actually doing this. The Crimson manual isn't of any help either in describing this functionality concerning comm drivers. I was debugging this it seemed like the program would run at least several times a second, when actual input is only changing every second or so. It also seemed to be hogging a bunch of resources despite there being no change in information received.

Click to expand...

On Power Up = Something you want executed before runtime. This will not be used very often
On Startup = Something you want to execute when the program loads

The OnUpdate on the comms driver will execute on every comms scan which will in most cases will happen more than once per second. If you send me your file I can see what may be causing the performance issues that you mention. This is however the proper way to read in raw data.

Thanks
Jeremy

If you look on page 115 in the help manual (Contents under the Help) It gives details on how the On Startup Up works. For some reason the manual does not define on Power Up.

I used on Power Up once when I had a Modbus network talking to some drives. The Comms bootup would time out before the VFDs got done with their boot up routine so instead of playing with the timer I just used the On Power Up.

Jermery is right in the OnUpdate will work. The only drawback here is when you have noise on your Comms. It may not be enough to hose your data but it can cause a random character to be created and your Port sees that coming in and reacts to it so it ends up with a bunch of triggers when there actually is nothing there or really nothing you need.

Also since you are not Commanding your device for data that you are getting data from, what tells it to broadcast. While your data may not be changing it could be sending the data out as fast as it can. Continuous broadcasting could be the issue you are seeing.

I found the "On Startup" section so thank you, odd that it would be in the display pages properties...

The issue with using calling the program every time On Update is that I have two PortInput calls, as I am reading TempA and TempB but do not know when either one is available (the input is cycling through the temps reported from the unit... an Omega iServer MicroServer to be exact). I tried fine-tuning the timeout parameter for PortInput but just can't seem to get it right, and if I have anything more than a second there are some weird behaviours coming up like TempA never updating since TempB is not changing, but as long as both temps are changing they will keep updating as expected. It's quite an enigma and that's not a great explanation but I think this On Startup will be just what I need.

Thanks again all!