Hello,
I have run into an issue with my program/cf cards in which I change a variable on Automation Studio using a watch window.
I am using a pp65 panel and Automation Studio 4.2.
I altered an existing program and used the offline install tool to program the cf card. I then put the card into the pp65 panel and turn it on. The program runs normally until a single variable is changed, and the change causes the panel to crash. The panel starts up in service mode after that.
If the panel is shut off and restarted the program starts and then crashes within 30 seconds. Reprogramming the card with the same program results in the panel crashing in a similar way as in the last sentence.
A new cf card can be used to get the program to run until the variable is changed. This has happened on a couple of panels.
Something in the program must be causing this, but why does the cf card continue to crash even when reprogrammed?
Hi @zachary.wolfe, when PLC is restarted to service mode, just go AS - logger and upload logger. Im sure there will be more information about cause of restart of the panel to service mode. you can take a print screen and share it with us.
As you said, the issue is probably in the program code rather than an issue with the card itself. Service mode means that a critical error occurred during runtime that the application couldn’t recover from. One possibility is that changing the value of this variable is causing a memory access violation or a divide by zero error for example.
In order to figure out what specifically is going wrong, you’ll need to take a look at the system log. This can be done from Automation Studio or by getting a log file off of the panel. There was a previous post that shows you how to do this here.
ok, it is looks like that problem is caused with tasks running in task class 4. You have two options how to investigate the problem. Try to record profiler and figure out execution time of all tasks in this task class. or disable all of them, restart PLC to run mode and then enable all tasks task by task. Be careful is it not always that last task before cycle time violation error is the one that causes the issue. Am I right that project is in development? then other option would be to return to the last backup that was running fine.
@kovarj This project is a modification of a completed project. I have a local copy with the changes, and a copy on the server without the modifications. I will go through task class 4 and see if I can find the issue.
Is the variable you’re changing local to a program that runs in task class 4? Or is it a global variable used in a program in task class 4?
The variable change may be a red herring, but it’s at least a place to start looking. A cycle time violation could be caused by many things, but the first thing I’d look at is your loops (i.e. WHILE and FOR loops) to ensure that none of them are taking a long time to run. If this variable is used in one of these loops it could be causing the loop to run past the scheduled end of the cycle.
The error has to do with the part of the program I wrote. I moved it to the two longest task cycles and the program started, but crashed after a short time. I think I somehow made an infinite loop or something. I will continue looking into this.
As you already suspect, it’s most definitely an infinite (or at least too long ) loop.
You are Adding 100 to what at the top? D005… And then you compare and sub D001? Is that correct?
What datatype are the variables? The problem could also be, that you compare to >= 0. So a USINT would go from 0 to 255 but never below!
This problem was caused by an infinite loop, as I removed the loop and the program functioned correctly. I commented out what I had and started over, and managed to make a version that does not crash. I made the loop much smaller and used some return functions to keep the program out of the loop if my condition wasn’t met. Thank you for the help.
) loop.