PLC frequently rebooting
Plitch
Posts: 39
I have a PLC that does some interesting rebooting behavior, and I can't figure our why. It's a bit complex, but let me explain the system and the problem:
I have need of a stand-alone snow measuring device. Mechanically, the device is an ultrasonic sensor than can run on 24 volts DC, the Basic Stamp PLC with Maxim 1270 A/D chip installed, a small breadboard with terminals and relays for two switched circuits, and two small solar panels, a charge controller, and two 12 volt 7 AH (alarm system) gel acid sealed batteries to power the whole thing.
I elected to use a Stamp PLC with A/D converter to control the system. The Stamp PLC program is fairly simple - it begins by turning on the power to the ultrasonic sensor (via a small relay), lets the sensor "warm up" for five minutes, then takes a series of readings by converting sensor signal voltage (0 - 10 VDC) via the A/D converter, averages them and turns the sensor off. It then turns on a radio modem via another small relay and sends the data using debug statements to a radio attached to a remote PC.
The system behaves oddly. During the night hours, it runs the program loop fine, but occasionally produces a maximum range sensor reading (PLC converts it to 9999 millivolts). This could be a function of too much sensor gain, and that's easily fixable. I need to do further tests to verify the kind of problem here. The PLC wakes up from a sleep every two hours, runs the entire program loop, makes readings, sends them to the data gathering PC, and goes back to sleep. However, during the day hours it won't complete the program loop. Instead it will reboot every six minutes consistently.
Here's some more facts:
This timing would coincide with either the unit taking 50 sensor readings, or just after it has taken the readings - perhaps when it is sending them? The power on of the sensor takes place almost immediately after the unit boots, so a power surge or voltage drop to the PLC shouldn't be the issue,
The PLC and sensor both draw 24 volts from the two 12 volt batteries. These are charged by the solar panels. There is a charge controller that limits the charge voltage to 28.2 volts (summer ambient temperatures). In addition, the PLC and sensor draw power from a 24VDC switching converter which is adjusted to provide 24 DVC if the input voltage to the converter is in the range of 20 - 36 VDC. This has been confirmed by VOM. The PLC and sensor see a constant 24 VDC.
The analog sensor produces an analog voltage in the range of 0 - 10 VDC which corresponds to a linear distance measurement. I have used a digital volt ohmmeter and confirmed that the sensor is producing the correct voltage for the distance to the "target" baseboard. When calibrating the unit, I confirmed that the PLC was capable of reading, converting and reporting the correct millivolts to match the actual volt ohmmeter readings across the scale from 0 to 10 VDC.
The unit is sitting out in a field approximately 100 feet from a residence. The next building is over 100 yards away. There are no industrial uses anywhere nearby. The unit has no external hard connections to any power or communications lines. The unit is in a grounded steel system case and the sensor cable is shielded and grounded from the sensor to the steel case. I would think electrical noise is not likely.
The program works fine all night, but fails during the day. I would therefor suspect either the power supply is having some impact or there is some kind of thermal condition. Last winter the unit exhibited the same behavior (with a different sensor) before I gave up and shut it down for the winter. I therefor suspect that the problem isn't purely thermal since it is equally likely to happen during a cold NY winter night. The power system has a substantially regulated constant 24 volts to the sensor and PLC. The unit reports voltage at the PLC, and the first nighttime report (after it gets over the rebooting behavior) is that the voltage is at 24 volts, meaning the batteries are fine even after the sun goes down. So it doesn't reboot due to low battery voltage or it wouldn't come back on line until the sun comes up and charges the batteries. In fact, it does exactly the opposite, suggesting that the cause of the reboots is not the batteries being exhausted. Using the digital VOM, the batteries are showing in excess of 24 VDC before sunup with the sensor and the PLC running. It seems there is adequate battery power available at all times, and it is regulated to 24 volts.
I thought perhaps the system is drawing more power than the 24VDC converter can supply. However, the system works normally all night, so I would guess this isn't the case. The code is written to insure that the sensor is off when the radio is on to avoid creating a maximum draw situation.
My best guess is that there is some kind of internal thermal situation in the PLC which is aggravated by daytime temperatures. I have checked all the external wiring connections (many screw terminals) and verified that all are secure. Perhaps there is a faulty component in the PLC or perhaps the A/D chip has a flaw?
Any help in diagnosing this one would be appreciated. As much a I love the PLC, I don't want to buy another just to confirm a diagnosis.
I have need of a stand-alone snow measuring device. Mechanically, the device is an ultrasonic sensor than can run on 24 volts DC, the Basic Stamp PLC with Maxim 1270 A/D chip installed, a small breadboard with terminals and relays for two switched circuits, and two small solar panels, a charge controller, and two 12 volt 7 AH (alarm system) gel acid sealed batteries to power the whole thing.
I elected to use a Stamp PLC with A/D converter to control the system. The Stamp PLC program is fairly simple - it begins by turning on the power to the ultrasonic sensor (via a small relay), lets the sensor "warm up" for five minutes, then takes a series of readings by converting sensor signal voltage (0 - 10 VDC) via the A/D converter, averages them and turns the sensor off. It then turns on a radio modem via another small relay and sends the data using debug statements to a radio attached to a remote PC.
The system behaves oddly. During the night hours, it runs the program loop fine, but occasionally produces a maximum range sensor reading (PLC converts it to 9999 millivolts). This could be a function of too much sensor gain, and that's easily fixable. I need to do further tests to verify the kind of problem here. The PLC wakes up from a sleep every two hours, runs the entire program loop, makes readings, sends them to the data gathering PC, and goes back to sleep. However, during the day hours it won't complete the program loop. Instead it will reboot every six minutes consistently.
Here's some more facts:
This timing would coincide with either the unit taking 50 sensor readings, or just after it has taken the readings - perhaps when it is sending them? The power on of the sensor takes place almost immediately after the unit boots, so a power surge or voltage drop to the PLC shouldn't be the issue,
The PLC and sensor both draw 24 volts from the two 12 volt batteries. These are charged by the solar panels. There is a charge controller that limits the charge voltage to 28.2 volts (summer ambient temperatures). In addition, the PLC and sensor draw power from a 24VDC switching converter which is adjusted to provide 24 DVC if the input voltage to the converter is in the range of 20 - 36 VDC. This has been confirmed by VOM. The PLC and sensor see a constant 24 VDC.
The analog sensor produces an analog voltage in the range of 0 - 10 VDC which corresponds to a linear distance measurement. I have used a digital volt ohmmeter and confirmed that the sensor is producing the correct voltage for the distance to the "target" baseboard. When calibrating the unit, I confirmed that the PLC was capable of reading, converting and reporting the correct millivolts to match the actual volt ohmmeter readings across the scale from 0 to 10 VDC.
The unit is sitting out in a field approximately 100 feet from a residence. The next building is over 100 yards away. There are no industrial uses anywhere nearby. The unit has no external hard connections to any power or communications lines. The unit is in a grounded steel system case and the sensor cable is shielded and grounded from the sensor to the steel case. I would think electrical noise is not likely.
The program works fine all night, but fails during the day. I would therefor suspect either the power supply is having some impact or there is some kind of thermal condition. Last winter the unit exhibited the same behavior (with a different sensor) before I gave up and shut it down for the winter. I therefor suspect that the problem isn't purely thermal since it is equally likely to happen during a cold NY winter night. The power system has a substantially regulated constant 24 volts to the sensor and PLC. The unit reports voltage at the PLC, and the first nighttime report (after it gets over the rebooting behavior) is that the voltage is at 24 volts, meaning the batteries are fine even after the sun goes down. So it doesn't reboot due to low battery voltage or it wouldn't come back on line until the sun comes up and charges the batteries. In fact, it does exactly the opposite, suggesting that the cause of the reboots is not the batteries being exhausted. Using the digital VOM, the batteries are showing in excess of 24 VDC before sunup with the sensor and the PLC running. It seems there is adequate battery power available at all times, and it is regulated to 24 volts.
I thought perhaps the system is drawing more power than the 24VDC converter can supply. However, the system works normally all night, so I would guess this isn't the case. The code is written to insure that the sensor is off when the radio is on to avoid creating a maximum draw situation.
My best guess is that there is some kind of internal thermal situation in the PLC which is aggravated by daytime temperatures. I have checked all the external wiring connections (many screw terminals) and verified that all are secure. Perhaps there is a faulty component in the PLC or perhaps the A/D chip has a flaw?
Any help in diagnosing this one would be appreciated. As much a I love the PLC, I don't want to buy another just to confirm a diagnosis.
Comments
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle
Post Edited (Leon) : 8/27/2008 5:58:06 PM GMT
Here's a couple more clues.
I have added a bunch of DEBUG statements to my program to determine where it fails. I found that it fails towards the end of the sensor warm up period. The PLC turns on a relay controlling the power to the sensor. It allows the sensor to function for 5 minutes using PAUSE statements to delay program execution. This is to allow time for a temperature compensation circuit in the sensor to "warm up." Then it takes a battery voltage reading and then takes sensor readings. I added a DEBUG statement just after the warm-up routine, but before any other action is taken. That DEBUG never gets printed, meaning the reboot happens during the sensor warm-up period, but after the relay has turned on the sensor.
I checked the battery and sensor voltages with a VOM while the program was executing, and the batteries were charging at 27+ volts and the PLC and sensor were receiving 24 VDC. In addition, the sensor was producing a 3.8 (or so) VDC signal which is exactly on target.
My serial port monitor software on the PC listening to the gauge time stamps all entries in the log. The reboots are six minutes apart. Given the time it takes to turn the radio modems on and off and the time for the warm-up, I am guessing that the reboot happens at the very end of the sensor warm-up but its guaranteed to be before the input voltage translation, so there's no reason to suspect the A/D converter has anything to do with this (not used in the program to this point).
The interesting thing is it seems to happen exactly at the same point in the program each time, and that would probably be at the end of a for..next loop that contains a PAUSE for timing purposes. Its kinda weird that a hardware error would happen at the same place in the logic each time,but given that the program runs OK sometimes, it doesn't seem to be a logic or variable size declaration error. The timing loop is always only executed 5 times and the loop index variable is a byte size.
Well, we will try cooling it off sometime soon.
Thanks.
If you want an educated guess, check on this. I suspect that if the relay is being controlled directly by the Stamp, if there is no back-emf protection diode, that's the cause of the re-booting.
Regards,
Bruce Bates
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Involvement and committment can be best understood by looking at a plate of ham and eggs. The chicken was involved, but the pig was committed. ANON
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Engineering
Thanks for the information about the optical isolation of I/O on the PLC. That's one less issue to investigate!
As to your comments about code issues; I have added a bunch of DEBUG statements that help identify where in the program the reboot is occurring. It appears to be at the exit of a 5 minute timing loop that does nothing but allow time for a sensor to achieve ambient tmperature readings before recording data. Here's a snippet or two:
'
[noparse][[/noparse]Declarations]
a_minute CON 60000
J VAR Byte
Warm_Up_Minutes CON 5
'
'
[noparse][[/noparse]code]
add DEBUG message transmission to indicate REBOOT has happened
'
DO ' do forever loop
GOSUB SensorOn ' Turn on sensor power relay subroutine
'
FOR J = 1 to Warm_Up_Minutes ' Allow sensor to warm up for a few minutes (5)
PAUSE a_minute ' 1 minute per pause instruction
NEXT
'
' added DEBUG here to indicate the program is about to read battery volts - no change in sensor power relay required
'
GOSUB ReadVolts
'
' added DEBUG here to indicate that program was about to sample & average ultrasonic sensor readings
'
' Program gets sample in a loop here
' Program averages and does converstion to scale here
'
GOSUB SensorOff ' Shut off power to sensor relay
' GOSUB ModemOn ' Turn on modem power relay
'
'Program sends results via DEBUG statements here
' GOSUB Modem Off ' Turn off modem power here
'
SLEEP 8000 ' go to low power mode for about 2 hours
'
LOOP ' continue infinite do loop when wake up occurs
'
'
[noparse][[/noparse]end of program]
'
END
When reboots occur, the program never gets to the DEBUG statement I added indicating it is about to read voltage after the first timing do loop (the "J" index). This (and the 5 or so minutes between each reboot) suggest to me that the reboot occurs at the end of that timing pause loop and occurs in the same place each time. Theoretically, it could also occur during the execution of the DEBUG statement which requires the modem to be turned on and off again, but there is no message about getting sensor samples, so the reboot has to be happening before then. The reboot has to occur at or before before the modem being turned on before sending the "about to read battery volts" message because the message never is sent. If the reboot occured when the modem was turned off, the message would be sent. The time between reboots remains exactly the same if those modem control instructions are commented out, so I suspect that the reboot occurs before the modem is turned on to send the "about to read battery volts" message.
I like your suggestion the issue is likely code since it seems to occur in the same spot in the code every time. I get the same amount of time between reboots and the same debug messages happen. That would certainly suggest code. However, the reboots are not consistent or random. Like each night since it was fired up, the gauge ran well last night from about 7:30pm to this morning. The output was exactly as intended and written. This does not suggest code, more like an environmental factor (temperature, EMF?)
As suggested in another post, perhaps a bad internal joint is thermally sensitive? Our nights here are now 45 degrees and the days in the 80's. The PLC is in an unvented steel equipment box, but should be within spec for operating temps. Maybe I'll stick a thermometer in the box today. I may also take the device apart today and be sure the STAMP and A/D chips are solidly seated as yet another debug step.
Here's what the output listing looks like:
<20080827190852.530>, REBOOT
<20080827191424.560>, REBOOT
<20080827191956.640>, REBOOT
<20080827192528.610>,reading battery volts
<20080827192558.820>,reading sensor
<20080827192721.700>, 3689,0.0000, 24.9100,20, Comment
<20080827214559.500>,reading battery volts
<20080827214629.660>,reading sensor
..... etc.
The one data line here has the follwoing values:
<year-month-day-hour-minute-seconds>, sensor millivolts (3689 is exactly right), depth (0.00 is right), battery volts (24.91 is about .25 volt too high - variable resistor for scaling needs adjustment), software version (20 is right).
By the way, this form (comma delimited) makes it easy to read the data file right into an Excel spreadsheet for further analysis.
Note that this shows three reboots (first 3 lines) that never allowed the program to progress to the "read battery volts" message. In addition, the reboots are about 5 minutes apart, consistent with the "J" timing loop being executed. The data line also shows that at 7:30 PM - just around sunset (not much solar array activity), the PLC was seeing about 24.75 volts (the volts reading is scaled a bit high).
Any comments you might have about this particular code causing reboots would be appreciated. I have tried to keep it simple and be sure all variables stay within bounds, but I know there are some features and limits of STAMP code I neglect.
I remembered we had a customer who had a PC connected to a project once and could not figure out why it was resetting all the time. In their case it turns out the PC was the culprit. It may not be the case here but it is another avenue worth exploring. Some PCs can go into standby mode after a certain number of minutes of inactivity. When this happens it could affect certain ports. Especially USB to Serial adapters.
Have you tried putting a DEBUG in the warm up loop? You could even cause it to DEBUG more frequently by increasing the warm-up minutes to 4 times the value they are and decrease the pause by 1/4. In that loop have the DEBUG statement print the value of J at that moment.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Engineering
I mentioned in my early system description that there is no wired connection between the PC and the PLC. I use a pair of XBee-PRO PKG-R RS-232 RF modems (radio modems). These are in "dumb mode" and they "look" like a wired RS-232 serial connection logically. But I don't think a transient from the PC can make it past the radio isolation of the PLC.
Once the PLC has a program on board, I disconnect the laptop I use to program the gauge in the field, connect the radio modem and reboot the PLC with a power interrupt. All communication is outbound from the PLC to the PC. The PC only monitors incoming transmissions to capture data - it does not perform any control functions or send messages out to the PLC.
When running the PLC program, the PLC turns on power to the modem, and then gives it 15 seconds to do a self test and come on line before transmitting data.
Your other point is a good on. If I put a DEBUG statement in the J index timing loop I could determine more exactly when the reboot occurred and if in fact it occurs in the same spot each time. I will do that.
By the way, the PLC spent all afternoon rebooting, and then at 7:30 PM produced a perfectly correct reading. I expect it will continue to do so until tomorrow around sunrise.
By the way I measured the interior temperature of the equipment box at 99 degrees F at noon in a bright sun with 80 degree ambient temperatures. I think this is within spec for the PLC.
Thanks for your comments
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Still some PropSTICK Kit bare PCBs left!
If you mean the ATN pin on the PLC, I duplicated the diagram on page 4 of the PLC instruction sheet to create the serial connection. In this scheme, ATN is connected to pin 4 of a DB9 male, which I believe is the DTR signal.
Why would the ATN pin cause these kinds of part-time reboot errors?
Pieter
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Engineering
So how would you remedy this? I would like to be able to both program the PLC and allow it to output data via the DEBUG command. Is there a way to both of these and prevent the reboots? I would certainly be willing to throw a switch to enable programming if that is what it takes.
As you suggested, I added a DEBUG inside the timing loop that seems to be the problem. A couple of times it rebooted at the end of the 2rd and 3rd iterations, but have taken a couple of successful readings since dawn (not typical behavior) Today is somewhat overcast here, but I'm sure the panels are still charging.
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Still some PropSTICK Kit bare PCBs left!
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Still some PropSTICK Kit bare PCBs left!
So far (only a couple of cycles) I have found (1) it still reboots with the ATN line grounded and (2) the reboot may happen in the middle of the timing loop (the J index PAUSE loop) at any iteration, or in one case, it rebooted while in the middle of a SLEEP command.
Here's a snippet of the log file with my comments added to the end of lines:
<20080830083419.940>, REBOOT ATN grounded, system restarted manually
<20080830083450.090>,beginning program
<20080830083621.320>,executed PAUSE 1 times
<20080830083736.630>,executed PAUSE 2 times
<20080830083851.930>,executed PAUSE 3 times
<20080830084007.180>,executed PAUSE 4 times
<20080830084122.480>,executed PAUSE 5 times
<20080830084137.530>,reading battery volts
<20080830084207.680>,reading sensor
<20080830084330.680>, 3665,0.0000, 24.5600,20, Comment produced a normal output line OK
<20080830084400.830>,going to sleep
<20080830105745.720>, REBOOT Rebooted while waking up? 133 minutes should equal SLEEP 8000
<20080830105815.820>,beginning program therefor reboot occurred at end of SLEEP
<20080830105947.160>,executed PAUSE 1 times
<20080830110102.460>,executed PAUSE 2 times
<20080830110217.600>,executed PAUSE 3 times
<20080830110332.900>,executed PAUSE 4 times
<20080830110448.210>,executed PAUSE 5 times
<20080830110503.310>,reading battery volts
<20080830110533.410>,reading sensor
<20080830110656.350>, 3658,0.0000, 24.6400,20, Comment produced a normal output line
<20080830110726.560>,going to sleep
I will let the gauge run "as is" for a while to see if I can find a pattern, and I'll share any analysis here in a week or some.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Engineering
I will be going out of town for a week, but when I get back I will take the PLC case apart and be sure that the Stamp and A/D cips are in their sockets tightly. If so, I'll have to get another Stamp (just a plain BS2-IC I believe).
Thanks for all your attention to this. It certainly is beyond my ability to diagnose. I still suspect some kind of strange thermal since the reboot doesn't always happen in the same place. For the moment, however, it seems to be happening at the end of the SLEEP command when the unit wakes up.
Pieter
How well-charged are those gel-cell batteries? Could you be getting a brown-out condition when the sensor comes on?
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Still some PropSTICK Kit bare PCBs left!
The batteries are well charged - the solar panels charge at a regulated 28.2 volts, and a DC-to-DC inverter regulates power to the PLC to 24 volts exactly. In addition, I have been careful to be ure the radio modem is off when the sensor is powered up and vice-versa. I have checked supply voltages when everything is powered up (at the same time even) and the senor and modem and PLC are all right on the voltage, no drop.
I was out of town for a week and not surprisingly the reboots continued. Today I took a new (never used) PLC and installed a new BASIC Stamp 2e and a Maxim A/D converter and replaced the entire PLC unit currently in the snow gauge. It's a bit too early to tell given the long cycle times between readings, but it appears the new PLC is no better off than the old one. Reboots continue.
Here's some more info:
Reboots can and do happen anywhere in the program. Sometimes the pause loop (the one with a "J" index - see post way above) shows a reboot after 1 loop, sometimes 2, 3, or 4. Frequently the program will reboot right after it comes back from a SLEEP for 2 hours. There is no programmatic consistency to the problem, so I conclude its probably not a software issue.
The "new" PLC has made a couple of readings, but the values are way off. It shows a sensor voltage of .012 when the sensor voltage is 3.670 and a line voltage of 4.21 when the measured value is 24.1 (the measured values are by simultaneous VOM). At other times, these readings have been right on the money.
So I conclude that (1) the way in which the program computes the voltage values is OK since we have a history that says the PLC has done it correctly before many times and (2) Since BOTH the ultrasonic sensor (analog 1 input) and line voltage (analog input 2) are affected and since the voltages present are known to be in range by VOM reading, I conclude that something is interfering with the PLC's ability to read the analog data right or causes a reboot. What that is, I don't know.
I am going to run the gauge for a day or two to see how if there is any change, but at the moment, I would guess that substituting an entirely new PLC didn't solve the problem.
Pieter
-Phil
Addendum: I guess I should provide some background for this question. In your first post, you mentioned that the problem is more acute during the day than at night. During daylight hours, of course, the charge controller is more active. It may be interfering with the DC-DC converter, or it may be throwing off enough EMI to interfere with the PLC more directly.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Still some PropSTICK Kit bare PCBs left!
Post Edited (Phil Pilgrim (PhiPi)) : 9/9/2008 5:15:35 PM GMT
In the meantime, I am running the code on the "old" PLC (the first one) now sitting on my desk with the 24 VDC transformer and converter attached. Of course, no sensor inputs. The result is it never reboots, but gives "noise" sensor output readings. A couple of conclusions:
(1) there was nothing internally wrong with the "old" PLC. Therefore the issue is somehow related to sensor input or power supply issues - not the software, not the PLC or AD chip hardware.
(2) The snow gauge has been generating some (but not all) out-of-range readings. Form seeing the noise in the "old" PLC sensor readings I suspect that some of what I thought were just "out of range" readings were, in fact, not readings at all. Apparently the PLC was not reading or perhaps the AD chip - Maxim 1270 was not processing the analog voltage data correctly.
Here's an embarrassingly dumb question :
The PLC has two terminals both marked "Ain Ground." Obviously this is for Analog Input Ground.
I note in the documentation for the PLC (Figure 11) that these are also called B-K12 and B-K11. I have been assuming these two terminals were electrically tied together, but a test with the mulitmeter shows they are not. My sensor has 3 leads - a +24 volts out, an analog voltage that varies with distance (0 - 10 volts), and a common ground. How should this be attached? Obviously the analog voltage goes to the analog port in question, in my case Ain 1 (B-K16). What do I do about the common ground lead? Apparently the two Ain GND connections behave differently, and I find no information in the PLC documentation to suggest a correct connection. Do I connect to one and tie the other to system ground?
Have you tried a simpler program on the stamp to see if its something where the code and hardware integrate?
I.e. maybe try a day with:
1) Just transmitting the some constants via the radio modem
2) Increase by one bit at a time, i.e. one relay, then another etc and build it up.
Or - have you tried with the relays/sensors disconnected in the box - if thats possible?
These things can be weird to track down, but good efforts so far.
James
I think the problem(s) is solved.
Here's what I found.
(1) I believe Phil Pilgrim first suggested grounding the ATN line. In my haste to try the fix, I grounded the wrong pin (blush) and then assumed that the fix didn't work. After tracing each and every connection on my "daughterboard" that holds the relay circuits, I found my error. I temporarily grounded the correct ATN line after rebooting, and surprise - no more reboots. I will construct a nicer ground line with a "run-program" SPST switch.
(2) The miniature relay that supplies power to the ultrasonic sensor had an intermittent contact with the socket on the output leg for sensor power. A bit of adjustment (AKA bending), and the problem went away - now I am getting sensor readings in range every time. Additionally, what I learned from this is that there seems to be a bit on noise ( a few millivolts on a 10 volt scale) in the system. I mistook this noise for sensor readings out of range when, in fact, there were no sensor readings, just noise. The Ah-ha! moment for me was when I realized that both the line voltage and depth sensor reading varied at the same time because the line voltage is measured on the sensor power line, and if there was no sensor power, there would be nothing but noise readings on both the sensor and line voltage readings. Such was the case.
By the way, the same program running on a completely naked (unconnected except for power and serial comm lines) PLC equipped with the same processor and A/D converter produces the same noise readings as the one in the gauge, so I assume that amount is inherent in the PLC.
So for the moment the gauge is producing measurements in range and no re-boots.
I really appreciate all the suggestions made by folks here, and in fact the suggestion to ground the ATN line was right on the money.
Again, many thanks for all your time and suggestions.
Pieter
Pieter,
'Glad you finally got it working!
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Still some PropSTICK Kit bare PCBs left!
As it turns out, the problem was not "solved", just reduced. In fact, the reboots have continued after insuring that the ATN pin was grounded when programming of the PLC was not in progress.
I decided to see if I could find other ways in which a transient might cause a reset of the PLC. My PLC controls two relays via Dout1 and Dout2, and measures two analog voltages via Ain1 and Ain2. I figured that anything external causing a reboot had to travel one of these paths.
I first made a software change to simple prevent Dout1 from activating the attached relay (commented out the LOW instruction). This seemed to solve the problem - about 99% of the reboots have gone away. At this point I have not tested the second relay circuit.
The Dout1 circuit is an exact duplicate of Figure 8 in the PLC instruction sheets "BASIC Stamp Programmable Logic Controller Package" 12/29/03. The relay coil is powered by 24VDC, but unlike Figure 8, there is a zener diode across the coil with the cathode at the +24 VDC end on the coil. Since this relay controls the power to a sensor which in turn provides a voltage between 0 and 10VDC that is proportional to distance, perhaps a transient was getting into the system via the signal line, not the relay circuit. So to test for this definitively, I disconnected the signal line and reconnected the relay circuit by removing the comment characters preventing the subroutine from toggling the pin. Reboots abound. Conclusion: The relay circuit (Dout1) seems to be the cause of the problem since the associated sensor input line could not be causing the problem (disconnected).
I should also mention that there is a voltage divider circuit ( a 22k and a 0-100k variable resistor) to drop the +/- 24VDC to the 0-5 volt range so that the Maxim 1270 ADC can translate. This is driven by the 24VDC line switched on and off by the sensor power relay (Dout1).
The Dout2 circuit is probably not the source of the problem since it is turned on and off many times per program loop, and when Dout1 was disconnected (but Dout2 was NOT disconnected), only 1 reboot happened in 24 hours.
So the question is: Does this all sound reasonable to engineering minds? If so, how do I fix it? I was thinking of scrapping the relays and using MOSFETs in their place. The sensor is a SensComp Mini-AE 24VDC that requires 30mA of current (2.0 Amperes during the .5 ms transmit pulse).
Since I am only bright enough to follow simple instructions, any diagrams showing how components would relate to each other, and recommendations for parts by number would be appreciated.
Thanks, Pieter