IO Error causes and fixes

[CReese]

Do you think it's possible this is defective hardware? We've replaced everything except the CPU (I think).

C

[BobO]

I'd like to see you clean up these messages first. Every one of these messages represents something that isn't quite right. If we aren't recovering correctly from those conditions, it could be causing the crash/reboot cycle, which clears itself after going through the program/run transition. Before you tweak anything, make sure you have a good backup, because if this clears it up, I'm gonna want to study the program to try to understand what isn't working right.

The "A mutliscan instruction..." message is due to something like an MRX/MWX still being active when termination code is run. Termination code is executed any time a stage is disabled due to jump or reset, a program is stopped through exit or halt, or a task terminates. If a stage/task/program contains a multiscan instruction, you should *always* use the success/failed bits to enable the transition. The best way to think about what is happening is like killing the power to your PC vs doing a menu shutdown.

The string buffer overruns aren't too big a deal, but as a rule, you really should be using the correct buffer sizes for whatever you are doing. When this message happens it is due to something getting truncated.

The array index out of bounds can be of concern because we prevented you from doing something your code was trying to do. Both the code being out of bounds and the PLC ignoring the request are bad. I would want to understand what is happening.

It may well be that these are all non-issues...things that happened while developing and simply haven't been cleared. Hit the Clear All button at the bottom and see if they re-occur. If they do not, it's likely not the issue. If they do, I'd clean them up.

As for the hardware, it's possible, but I'm leaning to 'no' at this point.

[CReese]

And the device driver error?

[BobO]

Could just be comm errors in your Modbus. May be related to the abnormal termination of the Modbus instructions. Any time a failed bit is set the device driver error flag gets set too.

[CReese]

Ok, well let me run this down. I've looked at these before and not been able to nail them down.

1. Attempted string operation was longer than the target string and was truncated ...

The operation is a STRGETB, getting 40 bytes from a string struct that is 80 characters long and putting it into an MHR memory location that exists.

There are four such errors.

2. The index error was an easy programming fix.

3. The forcibly terminated was indeed a jump in parallel with an MRX operation. I fixed that.

I'd still like advice on the above. I'll see if the thing still kicks over out of run.

Colin

[BobO]

1. Attempted string operation was longer than the target string and was truncated ...

The operation is a STRGETB, getting 40 bytes from a string struct that is 80 characters long and putting it into an MHR memory location that exists.

There are four such errors.

I am super confused. That message is a generic message generated by the driver layer when it doesn't have detailed parameter information...STRGETB doesn't generate that message.

There was a bounds check bug in STRGETB in Rel 1.0 firmware. It was fixed in 1.1.

If you are willing, please email your program to me.

[BobO]

Never mind, I figured it out. DmD takes the system error code and generates a message from it. It's wrong in this case.

There was definitely a bug in 1.0 firmware and it would wrongly say the buffer was too short.

[CReese]

So it is safe to ignore?

[BobO]

So it is safe to ignore?

No. It didn't work right in 1.0 (the instruction failed), but if you are getting it in anything since then, it should be a valid error. Truncating isn't the worst thing if there was nothing critical in the cut off part, but it indicates that you are trying to write something somewhere it won't fit.

Or...the instruction is still broken, and if so, I very much want to know how.

[CReese]

Alright, we saw it again. Here's what I get:

In Warning
------------------------------
Buffer overflow
Device driver reror
One of more IO masters are indicating a problem with a module

In event logs
------------------------------
Many cycles of :
PLC rebooted following hardware timeout
System was turned off
System was turned on

Then most recently, about twenty of the error:
Critical error occurred in the IO system

In I/O System
------------------------------
Channel failure warnings on unused analog channels in slots 2 and 4


What is this critical error in the IO system?
Colin

[BobO]

What is this critical error in the IO system?

Can be multiple things, but it's probably a bad module ID. As we scan the base, we check module IDs to make sure they haven't been pulled or failed or whatever. If I see the wrong ID (or no ID) it gets flagged. This type of I/O error is considered critical and takes the controller out of RUN mode.

This feels like a very systemic issue...bad base, bad hardware, bad power, horrible bit of electrical noise...

[CReese]

Ok, so what sort of IO issue could create the critical error? Overvoltage, perhaps a dip in power supply?

Colin

[BobO]

I would look for a noisy event or flaky power.

Has all the hardware been replaced?

[CReese]

Yes, except the CPU. I may replace it today.

The good part is we are about to fire up an identical system, so if it's systemic, we'll see it. If it's hardware or a miswire, I'd guess we don't. You don't often get such good data.

C

[CReese]

I don't know where this would go, but there should definitely be a warning or error for attempting to jump to a non-existent stage. It is a very annoying thing to debug. Program is running, but no active stages ...