Red Lion programming issues and answers

Rik

Member
Join Date
Oct 2009
Location
Arnhem
Posts
3
Hello all, first of all I'm new on the forum but had a lot of contact with the Red Lion helpdesk who are really helpfull (Dan, Will) :nodi:
Still I keep on running into different problems for wich I hope somebody can help me with and maybe anyone can use my experience.

In the beginning when I started using Red Lion it was just for small setups with 1 PID controller and an analog input card. It annoyed me I had to use an analog output card to write a value to the input of the PID if I wanted to use a calculated variable as input. Fortunately I later found out it was possible to write the data to the AltPV register by turing the ReqAltPV register on :) This made everything much easier.

Also I had a lot of speed issues between the Red Lion master GT controller and the 15" HMI screens which where, in the end, caused by me using OPC server instead of Modbus over ethernet which turned out to be really fast.
Together with this problem I had the issue of the whole system slowing down while logging. Ok I was logging over 100 tags every second but still... After switching to modbus this issue was mostly resolved but in the charts and web interface you still see the system hanging every 2 minutes. The web interface really slows down the system when using OPC.

At the moment I got 3 Red Lion systems up and running including CSMSTRGT with 15" touchscreens and a lot of different modules. one of the test skids I'm working on now is going to be send offshore to an oil rig. For this reason it has to be really stable and I have some issues with that. I'm using 7 PID controllers of which I'm using the AltPV register. For this reasing I'm running a main() function which is converting floating point values from different coriolis meters over modbus to integers which are sent to the PID controllers. I want this function to run 2x a second so I have an init() function which is called at startup, from this function I'm calling the main() function which is set to run in the background en read always. This function starts with an infinite for loop for(;;) and has a delay of 500ms in the end. this function is not running at the interval I want to because sometimes it runs faster and sometimes slower than 2x a second. If I call the main function from the Tick() value once a second without the delay of 500ms built in, the function gets runned about 15 to 20x a second. Ofcourse faster is better but I got the impression that this speed is crashing my system every now and then. Red error screen on the web interface.. Don't want that on an oil rig... Does anybody has any experience with timing functions or the way the run in background and read when referenced stuff works? I've been trying a lot of different methods but none of them are stable.

I hope somebody can help me with this issue and I hope I can be helpfull to everyone else on the forum.

Thanks,
Rik
 
Does anybody has any experience with timing functions or the way the run in background and read when referenced stuff works?
My experience with this is limited, but I haven't had much luck using the G3 for time-sensitive applications. In its defense, however, it's not a deterministic controller and is not really intended for those kinds of applications. (It's an HMI, for pete's sake.) Based on your description, it seems like you should consider using some PLC-based device to handle the data conversion, since timing is critical.

Have you looked at the DispCount variable in Crimson? I don't know the rate offhand but it's somewhere in the neighborhood of 10 Hz. You can set up a formula tag to reference individual bits of this variable, then trigger actions at a particular rate. I use this frequently to make objects flash on the screen and it seems fairly consistent.
 
What you are doing now, the infinite loop in the background is the only (recommended) way to get anything to happen faster than once a second. However, you are correct that sometimes it will run faster or slower. This is based on the rest of the system load. If there is a lot of items on a particular screen, meaning more comms and a longer time to 'draw' the display, the program will run slower.

Regards,
Dan
 
Ofcourse I'm not using the HMI for the controls, the PID's en main() loop are running on the CSMSTRGT so that shouldn't have anything to do with the display update rate. But, it does matter if you have the web interface up and running....

Regarding running in the background, if you use a delay, will all the function wait for this or can you use multithreading?

Greets,
Rik
 
Using a delay will not help with anything, all it will do is slow down the background program. Here is a basic rundown of how programs run:

* Programs may be set to run in the background or foreground.

* Running a background program queues it for execution by a low priority task that runs when the system is not doing other things. A program can only be in the queue once, but is removed from the queue before execution, so a program may add itself back to the queue. The task executes only one program at a time, and pulls them from the queue in the order they were added. If a background program doesn't return, no other background programs can execute.

* Running a foreground program runs it in the context of the calling task. For OnTick and other UI events, this task is the user interface task. For tag triggers, it is a scanner task. For raw port handling, it is the comms port's task. If a foreground program is called from a background program, it runs in the context of the thread that processes background tasks. In other words, it runs in the background. If a foreground program is called from another foreground program, it will run in the context of the task that called the original program. If a foreground program does not return, it will block execution of the task in question. This is not good.

* Using Sleep is generally a bad idea. It will pause the task that is running the program. For a background program, this does nothing useful. For a foreground program, it will allow other lower-priority tasks to run, but will still block the task that called the program in the first place.

Regards,
Danq
 

Similar Topics

Hi, I have a Red Lion E3 io counting output from weld cells, connected to a PTV station for the visuals. Our number of weld cells is set to...
Replies
2
Views
1,533
Any thoughts on how I could get rid of all the individual pages and just have one page that shows all tools that are going to expire as well as...
Replies
2
Views
1,532
Can anyone see what is wrong with this program? every time it gets to the Cell2 page it doesn't scroll any further. The goal is to have it switch...
Replies
2
Views
1,457
I am pretty new to Red Lion and Crimson and I am trying to figure out a way that I can change the screen and Display a message based on the Inputs...
Replies
3
Views
1,414
I am working on learning more about programming, and am having to try and teach what i know to new hires in our maintenance department. In order...
Replies
9
Views
5,680
Back
Top Bottom