PLC-5 AO Scaling in modules?

[waterboy 7]

When using the Analog input and output modules in a PLC5 rack there are entries for raw min and raw max. In an AI module this scaling works as I expected it would, But in the AO module those entries don't seem to have any effect. The program I am looking at uses 0-4095 for module scaling entries and ladder does all the scaling. I am experimenting to see if scaling in the module is a better option. It sure is cleaner! Can anyone explain why these entries are in the AO module if they don't have any effect? And also what are the data sizes for the BTW and BTR block for an AO module? I know there is a requirement for AI modules depending on revision but what about AO? A few of the programs I am seeing are not configured correctly and if not right you get the message that "not all of the data could be written..." and I am seeing a lot of that :)

[Mickey 71]

Best to leave the input scaled at 0-4095 in the module and use ladder to scale your engineering units. Better resolution. What analog output module do you have? Complete catalog number please.

[waterboy 7]

Scaling in the ladder is better? Really? I wouldn't have thought that. If I need a range from 0-50 feet I scale from 0- 5000 in the module I get the equivalent of 2 decimals of precision in an integer. Works pretty well. And the question remains as to why the A/O scaling does nothing. Modules are 1771-OFE and 1771 IFE I found data length spec of 13 words for A/O BTW and 5 words for BTR A/I is either 37 or 39 words for BTW and 20 or 22 words for BTR, the larger number being for the C revision's "Calibrate" option.

[Mickey 71]

The modules are 12 bit modules the best resolution your going to get is 0-4095. You can scale the 1771-OFE if you want. See pdf below. ofescaling.pdf

[waterboy 7]

I have applied the Scaling value to the OFE in the mudule dialog as opposed to the specific addresses as the PDF indicates, but the output doesn't change. I must have something else going on that prevents it fom working. I'll keep poking at it.

[OkiePC 14]

If you use the Module Applet within RSLogix5 to make changes to the scaling, those changes then must be "sent" via BTW to the module. The applet itself can issue the changes via a one-time block transfer of the data. Notice the button on the applet marked "Accept Edits" should become available when you edit one or more of the fields. When you press that button, you should be prompted whether or not you want RSLogix5 to send the new data to the module. You can do this without having to use the dialog box if, for example, your RSLogix5 project does not have the I/O configuration data filled out. I prefer the Module Dialog boxes myself, so I always take the time to set up the I/O configuration and save it with the project. So, you should be able to change those values in the raw data tables, and then trigger the ladder logic BTW for configuration of the module to occur. NOTE: This will depend on how the block transfer writes are programmed. Some folks use the First Scan bit to condition the BTW, their thinking is "Why keep sending the same data to the module over and over again?". Also, some modules will set a bit when they have not been configured and this may be used to condition the BTW. Personally, I like to alternate the BTW and BTR the way that RSLogix will insert the rungs for you. In rare cases I may add conditions to the BTW configuration logic so that I can BTR a module faster, for example. BE VERY CAREFUL when sending an update to a card. The update will apply the data for all the channels so if it is not what is already in the card, you could encounter problems, perhaps even on a different channel. It is wise to document exactly what you have and get familiar with all the channels in use before proceeding. So, closely examine the logic for your module configuration, and when you are ready to go, try the Accept Edits button in the module dialog box. Edited 3 Jun 2011 by OkiePC

[paulengr 44]

This case is talking about an output card. You need to write to it basically continuously (or alternating BTW/BTR) so the above information doesn't matter. Since there's nothing being passed back (other than status), you could theoretically delete the BTR's. That being said, there are certain cards that do NOT take kindly to being continuously reprogrammed and either act erratic or eventually tend to crash on you with no explanation whatsoever. We went through PILES of cards for a while on one machine before figuring this one out. The best way to set up your BTR/BTW's to avoid these kinds of problems is to use the wizards to insert the instructions at least initially, even if you have to move them around to where you want them. The wizards know when to initialize on first scan and when not to. In practice unless it was one of the "bad" cards, for read cards, I tended to slow the update times down to once every 30-60 seconds. The maintenance department had figured out that you CAN do a RIUP (remove and insert under power) on a 1771 chassis and it works often enough without any ill effects (frying card, chassis, CPU, or power supply) that it became a practice before I started working there. They had unfortunately already conditioned production to the idea that this was a good idea so all I could do is wait for something unfortunate to happen (damage which took down the PLC anyway). It never did, so the program needed to be written to support RIUP whether it was OK or not (it's not) on a PLC-5.

[OkiePC 14]

I agree with this too. I have not had problems with "bad cards" but I have seen them lose their config data for no obvious reason, and those programmed to write the config data only on first scan or other "custom conditions" did go haywire. The alternating BTW/BTR will take care of that. My sole PLC-5 at this plant had been the victim of numerous RUIP incidents (all without any adverse side effects) before I assured them it's a bad practice. Since this system runs a refrigeration system that can affect the entire plant and it has manual bypass switches for almost everything (except alarm relays), now we go ahead and use the bypass HOA switches to keep things running while power cycling the rack containing a card that needs to be pulled (usually just to replace fuses). Then we get calls from the alarm company but that is simple to handle unlike frying a power supply or backplane.

[waterboy 7]

I am clear on all that has been said so far (though I have NEVER been tempted to RIUP a PLC5 module, I don't even like to do it to CLX !) The problem I see at the module is that I can change the raw min and raw max, press accept, and I see a difference in the DAC and Value entries proportional to the scaling I entered, but the 4-20MA signal out does not change in the same way. It doesn't change at all. I expect to be able to enter 0 and 300 in the min and max, then write 300 to the channel using ladder and have 20ma at the output. I see the value of 300 written to the channel, but I don't get 20ma output from it.

[Mickey 71]

Can you post your program here?

[waterboy 7]

Not today - Is there something specific I should look out for? All I am doing is to take an integer value and MOV it into the OFE Channel 1 Data register (n7:xx) . The output current changes based on what I put into that register, but if I leave that register alone and only change the scaling in the module, the DAC value changes but output current does not change. To workaround this I am scaling in ladder using a MUL instead of a MOV but the destination of both instructions is the same N7:xx register. This works but isn't what I want to do. And before you ask, no I am not doing both the MUL and the MOV at the same time. :)

[Mickey 71]

Nothing specific just sometimes someone can spot something while looking at the actual program. I have never tried what you are trying to do and don't have a module to test it on. I just use the 0-4095 ( no scaling). Maybe someone who does can test it on there unit.

[waterboy 7]

me either, so its possible that the scaling values are intended to do something else. Or perhaps never intended to work at all.

[OkiePC 14]

I have seen programs in which the config data is unconditionally copied from a separate location, overwriting what is done in the module wizard, so you might look for that. I believe that if that is what is happening, the wizard (when closed and re-opened) will show the values contained by the BTW and would appear to revert to old values after you make the change. How about a screenshot of the module BTR and BTW rungs? And a screenshot of the module config dialog? Edited 4 Jun 2011 by OkiePC

[paulengr 44]

Look at the BTR data, word 5, bits 0-3 which indicate whether the scaling/input data is valid. Second, don't necessarily believe what Logix 5 is telling you. Look at the words in words 1-4 for the actual RAW data that is being output to the DAC (digital-to-analog converter) on the card. I've found numerous cases where the wizard (the display in Logix 5) is dead wrong. Third, be careful about just what numbers you put into the max/min values. You can't put ANYTHING in there. They have to be right, and if I read the card manual correctly, it is limited to +/-9999 but it also depends on whether or not you are in BCD mode or binary. No point in doing anything but 2's complement binary on a PLC-5 (the BCD stuff was for PLC-2/3 compatibility). Fourth, read over the calibration procedure in the user manual (literare.rockwellautomation.com, enter a search for 1771-OFE). Be sure that someone hasn't recalibrated it incorrectly if the ranges are all off and the software side is working correctly according to the input data you've put in and the outputs, if you can't get your outputs to change even with defaults (0 and 4095, or +/-4095 depending on whether you are using 4-20mA or +/-10V).