Digital Thermocouple Input for Micrologix 1000?

[cleansc]

Thanks for the additional information. The Omega and Calex 5611 low-speed modules output up to 510 Hz (for <500C) and 1100 Hz (for up to 1000C), and the mfrs indicate that these are for use on "normal" PLC inputs, so from the above, I'm interpreting that the normal scan time can be interrupted to read these devices adequately?

I ordered the cable from the source suggested by Ron_Beaufort and hope to be able to actually extract the program running in our machines. However, a daunting realization occurred to me. Since these are OEM machines, it may well be the case that the PLC code is only accessible with a password. I'm not an advocate of inappropriately exploiting others' IP; however, this OEM went out of business and left its customers high and dry. The least they could have done was provide the access credentials and said "good luck with that". If this turns out to be the case, would there anyway to access the code on an A-B ML 1000 via brute force?

Worst case, the control scheme on these machines doesn't seem to be horribly complicated. The system runs two timed cycles, while handling two temperature inputs and a few contact inputs and outputs of three motor/fan contacts, a steam solenoid valve contact, activation of an external refrigeration unit, and couple of indicator lights. It would not be impossible just to reprogram a new controller from scratch, but we would prefer to avoid going down that path.

 

[Lancie1]

I'm interpreting that the normal scan time can be interrupted to read these devices adequately?

I am sure that your MicroLogix can read these inputs.

For some other stuff, the less said, the better!

 

[cleansc]

I am sure that your MicroLogix can read these inputs.

For some other stuff, the less said, the better!

Well, we'll see what happens when we try to hook it up.

Worst case scenario, if they have this OEM locked and we have to rewrite the program, is there any reason why I shouldn't just buy Micrologix 1000 on Ebay for ~$100, a couple of these Omegas modules, and just program it with the free the RsLogix Lite software? Granted, this isn't fancy, but we're going for functionality and we're on a budget here!

 

[Lancie1]

The most serious reason why you should not would be that you have time-consuming problems in duplicating the original program exactly with the new equipment.

Some advantages to go with new equipment would be: You can leave the old unit in place and operating until you get the new one programmed and tested. You will have updated T/C modules with a warranty, and hopefully some program software supplied by Omega.

You might be able to clear the old Mircologix memory to a blank program (deleting any password in the process), and then reprogram it with your own version. I don't suppose that there was an old faded wrinkled coffee-stained program print-out left in the bottom of the PLC hazardous-area enclosure?

 

[OkiePC]

If you contact A/B, and testify to the non-existence of the OEM, sign your name in blood, they can get into the Micrologix for you and recover the logic contained inside.

As for using more of the ML1000 along with the converters to save money, if the numbers add up, go for it. Note that the free software will also program the ML1100 which is going to be a much more capable micro PLC.

 

[cleansc]

Some advantages to go with new equipment would be: You can leave the old unit in place and operating until you get the new one programmed and tested. You will have updated T/C modules with a warranty, and hopefully some program software supplied by Omega.

Agreed. I would rather just wire up a separate one and program and verify it offline, while sipping coffee. Still, I'd rather just use a secondhand ML 1000 for this purpose; then we can just upgrade our existing machines, updating their in-kind PLC in-situ and just swapping out their TC modules whenever needed.

Unfortunately, Omega couldn't provide any code but Calex did offer some. But that code used the high-speed counter. I haven't dug into it yet, but someone alluded to it earlier, but is it really feasible to be able to use one HSC to process more than one input or am I better off using going with the slower speed input I/O's(10-510 Hz)?

I don't suppose that there was an old faded wrinkled coffee-stained program print-out left in the bottom of the PLC hazardous-area enclosure?

Ha. No, they left that gift out.

 

[cleansc]

If you contact A/B, and testify to the non-existence of the OEM, sign your name in blood, they can get into the Micrologix for you and recover the logic contained inside.

That's definitely worth a try. This OEM is long gone. Otherwise, I'd have them on the spot fixing my problem! Having the code would certainly save time, not to mention that this machine contains an explosive solvent vapor inside when it is operating, so I certainly can raise the argument that replicating the OEM's control scheme is a key safety issue. I don't think it's an overly complicated program, but it just has to be right.

As for using more of the ML1000 along with the converters to save money, if the numbers add up, go for it. Note that the free software will also program the ML1100 which is going to be a much more capable micro PLC.

Actually, I just found and bought a ML 1000 Series E for $75. Hopefully that will do the job. If nothing else, I've got something to tinker with!

 

[jrwb4gbm]

I am retired. I would be glad to help you with your programming. Feel free to send me a Private Message with a phone number if you want to. I would be glad to share what I have learned about programming the MicroLogix 1000 over the phone at no charge. Sometimes a single phone call will answer questions that would take days back and forth on the forum.

 

[cleansc]

Update - New Program Modification

Thanks for all of your input on the preceding thread. Here is an update.

As background, we were having problems getting accurate temperature readings on a piece of equipment (textile dryer and solvent recovery system) controlled by a Micrologix 1000 using Sensorpulse MSP I/O modules to process the thermocouple signals. We suspected that the Sensorpule modules might be bad and although they are long off the market, we were able to obtain a couple of used replacement modules that had been salvaged from same type of equipment we are using. So, we thought we would be good to go. However, the temperature readings are still all over the place (unstable and inaccurate), causing the machine to not run properly. The PLC is coming up with values, but they are not reflective of the real world temperatures. They're in the order of magnitude but way-off what would be explained by a TC calibration issue (e.g., giving a reading of 30F when the temperature is actually 90F). We have checked the thermocouples (J-Type), their continuity, polarity, etc. and they seem to be OK (got a digital thermometer arriving this week to double check calibration). The same thing is happening with two independent TC's so it would seem to point to the Sensorpulse interfaces as being the issue. So, I'm wondering if there is some breakdown between the what the Sensorpulse is transmitting and how the PLC is handling it. The Sensorpulse are configurable, but I don't have the cable to access their configurations. Since they came off of very similar equipment, we assumed that they were mated with the same code on that machine. Who knows...it could be that there is a slight revision tweak that is causing these problems and I don't see a way to definitely to root cause it. Sorting out what is happening with these Sensorpules will now probably take longer than just developing an alternate solution using a commercially available and simpler approach.

Fortunately, I was able to extract the PLC program running on this machine. So, based on your previous suggestions, I have attempted to modify the PLC program to accommodate the Omega DRP-8611 (=Calex 8611) I/O modules. Note that these variants are intended to be used with "low speed" inputs. Since our PLC only has 1 HSC and we have two separate thermocouple inputs to process, using the HSC variants did not seem like a good option. I THINK these should work for our purpose. They generate a 50/50 square wave frequency of 10 - 510 Hz linearly proportional to a temperature range of 0 - 500 C. Our application would never see anything higher than 225F (107C), so conservatively, the range of frequencies we are practially concerned with is 10 - 150 Hz.

So the question is how to program for this. I considered using the STI to read the pulses on a consistent time base. However, it seems that accurately counting the pulses in the lower frequency range for two inputs would require impractially long interruption periods. So, my initial attempt is to just incorporate the counting/timing logic into the main program. At the very extreme end of our range at 150 Hz, the pulse duration would be 3.33 ms, so I am ASSUMING that total scan time for this program will be less than that. Note that, per Calex recommendation, I also set the input filter to 0.5 ms so that may factor in as well. ** Am I being realistic about the timing window here? ** I bought a cheap spare Micrologix 1000 on ebay to use as a development lab / spare so I can at least fully test and confirm this program on PLC and Omega hardware and with actual thermocouples, all prior to downloading it to the production unit.

If you are so inclined, I have attached the old program written for the Sensorpulse as well as the new modification for the 8611.

The rest of the program seems to work OK, so the bottom line here is that we need to get two accurate temperature values (in F) into N7:14 and N7:19. The Sensorpulse code was designed to do that through the STI and Subroutine 6. In the new program, I have just added two sections at the bottom of the main program (starting at rung 33) to count the input pulses over a 1 second period and then convert them to the F temperature value. I cleared out the STI and subroutine, but there is still some residual baggage from the old program in the tables, etc, which can be cleaned up.


So, before I charge forward, I would welcome any constructive advice that anyone can offer. Note that I am not a trained PLC programmer (just a hack) and even the operation running this equipment is not my daytime job, so I'm sure you'll find a lot of rookie errors. Keep in mind that we're just looking for a reliable solution to reading these temperatures and getting the equipment running, even if it doesn't meet the standard of an elegant solution.


Any input would be highly valued. Thanks!

 

[OkiePC]

...the range of frequencies we are practically concerned with is 10 - 150 Hz.

10Hz = 0.100 second pulse width duration

150Hz = 0.006 second pulse width

I think you will need a faster PLC. The ML1000 is relatively slow when compared to the ML1100, 1200, 1400, 1500. I have a program with a considerable chunk of indirect addressing running in a ML1500 and the total scan time rarely breaks above 2ms. I think this is about 5-10 times faster than the ML1000.

You will need to be able to detect the difference between a pulse width that is one or two millisecond different when it changes...I have no time to look at your program today, but will have a look later.

If you could program multiple interrupt actions to update your math when either state change occurs for any of the sensors, this would be ideal. if the PLC can run at a <=1ms average scan time and has 1ms resolution timers (not available in the ML1000), then the logic could be even simpler without special interrupt instructions.

 

[Lancie1]

At the very extreme end of our range at 150 Hz, the pulse duration would be 3.33 ms, so I am ASSUMING that total scan time for this program will be less than that.

You need to MAKE it less than 3 ms. You can work toward that by: keeping your program as short as possible (probably it can be reduced and shortened a lot - I see a bunch of bits that are probably not needed and can be done without; Counters C5;2 and C5:3 could be deleted as they only count from 0 to 1 while two timers count from 0 to 60 - use the Timer Done bits in place of these Counter Done bits and change the other logic so memory bits are used instead of counters); and by only reading ONE of your two termperatures at a time. For example, set up one timer, and when it is 0.01 to 1 seconds, read the first temperature, and when it is 1.01 to 2 seconds, read the second temperature. This should shorten the scan time, but still read both temperatures every 2 seconds.

You will need to be able to detect the difference between a pulse width that is one or two millisecond different when it changes...

Looking at the ML 1000 specs on page A-8 of the user manual, for the DC versions, the minium time to read an input (minium switching time) is 1 milisecond (0.5 On delay and 0.5 off delay). It is do-able, but only barely if you have a DC Input version and not an AC-Input version. The AC version minimum input time is a whopping 40 mS! Your results may not be satisfactory unless you minimize the program scan time.

I haven't dug into it yet, but someone alluded to it earlier, but is it really feasible to be able to use one HSC to process more than one input...?

Yes, it can be done by a method called "multiplexing". What you would do is switch the function of your one HSC input by using two spare PLC ouputs (and maybe two external relays) to alternately switch your two temperature inputs to your one HSC input, say every 2 seconds. Because your program knows WHICH input is being read at any time, you can control what temperature the high-speed counter is reading at that time.

 

[Lancie1]

Apparantly the original programmer added a new timer every time he blinked. Extra timers make the scan time longer and will make reading the thermocouples more difficult. Timers T4:2, 3, 4, and 5 could be replaced by one 194-second T4:2 timer and some comparison instructions in place of DN bits. Timers 7 and 8 are only controlling a light flasher with 0.5 second 0n and Off times, so should be replaced by one S:4/9 alternating bit from the PLC internal free-running clock.

 

[cleansc]

I think you will need a faster PLC. The ML1000 is relatively slow when compared to the ML1100, 1200, 1400, 1500. I have a program with a considerable chunk of indirect addressing running in a ML1500 and the total scan time rarely breaks above 2ms. I think this is about 5-10 times faster than the ML1000.

For the new program, as currently written, I quickly added up all of maximum evaluation time (greater of true or false) for each instructions, and it is 1.88ms. With additional PLC overheads, etc., is there any rule of thumb on what the total time between scans might be?

I didn't add up the older version of the program with the Sensorpulse but I'm sure it was much longer. S:22 register contains a value of 1 (x 10ms) for maximum observable scan time, but I'm not sure that tells me much other it was below 10 ms.

You need to MAKE it less than 3 ms..

Good suggestions. If the maximum instruction scan time is 1.88ms as noted above, it seems I should be able to cut it in half. Timers alone account for almost 25% of that. This unit has DC inputs, so at least that's in my favor.

Yes, it can be done by a method called "multiplexing"...

That sounds like a possibility if I can't get the scan time down. I'm trying to envision how this works. Do I understand correctly that one would alternate the PLC output(s) from within the program to switch the relay(s) alternately open and closed between the two I/O modules and the single PLC input?

Apparantly the original programmer added a new timer every time he blinked.

Thanks for the additional tips there.

 

[Lancie1]

Here is a revised version with about 6 fewer timers, but with same functions. I did not verfiy the changes so you could see where they are. I added some comments to take care of any questions about deleting timers 3, 4, and 5. The comments allow you to see the rungs that now do the same functions with one T4:2 timer. Comments do not add to the scan time because they are not saved in the PLC, so the more the better.

With a little more study, other counters and bits could be deleted. There are many pairs of Latch and Unlatch bits that could be replaced with 1 OTE.

 

[Lancie1]

Do I understand correctly that one would alternate the PLC output(s) from within the program to switch the relay(s) alternately open and closed between the two I/O modules and the single PLC input?

Yes, I have successfully done a similar method where I used one analog PLC input to read 9 different voltage values at different times. Using outputs to read different inputs is sort of counter-intuitive, but for small limited programs, there is no reason that it cannot be made to work.