Help with BTW and BTR to OFE module error?

[waterboy 7]

Just got off the phone with Rockwell Tech Support trying to solve an error bit problem and got more confused than helped. Specifically I'm dealing with a PLC5/20E and 1771-OFE Analog output module and trying to learn all about it. I have my BTW and BTR configured using N registers. Data lengths are 13 and 5 respectively. Data seems to be accurate. The BTR trips the ERROR bit fairly often but clears just as quickly so it's not noticable to operations. The error in the control block from word 2 is -5 which translates to "the checksum of the block transfer read data was wrong" When I asked Tech support about this I was told to simply not use the BTR at all (for an OFE), I just don't need it. From what I have read I guess I could agree with that since all I would see are DAC values and a few error bits. But I would still like to know why I am getting these errors. If that is just normal operation I can live with that but I never noticed them before now. Second thing they told me was to use a BT block for the control word and not an N register. No reason given just that it should be that way. Any thoughts on this? Third thing was that I should trigger the BTR with a BT registers /EN bit. Currently we use a 1 second timer bit and a ONS. Again no real reason why one is better than the other. I've never used a BT register before and there are none in use here. Is there a performance penalty to using the /EN bit vs. polling only every second? Thoughts? And lastly that I have to enter the Scaling values for the BTW command directly into the Data file using Words 6-13, since there is no GUI that populates these locations. I understand what these words are from the documentation, I just assumed (till now) that the Raw Min and Max that we entered in the setup GUI were these values. Since there are values in the GUI (0 and 4095) but not in words 6-13, where are the Raw Min and Raw Max values that the GUI populates and do I indeed need to hand populate words 6-13? Thanks in advance for the help, Just when I thought I was getting a handle on this. . .

[TConnolly 13]

No idea on the first on. Using the EN bit keeps pending block transfers from stepping on each other and lets them go as fast as they can.

[waterboy 7]

Block transfers can step on each other?? with what result? Oh wait I see, the read and write can step on each other.. Maybe that what the error is from... Edited 10 Jan 2008 by waterboy

[Guest]

Greetings Waterboy ... don’t get discouraged ... if all else fails, give me a call and I’ll talk you through it ... that should be a last resort though ... you’ll learn more if you’ll just post your code and let us help you over the rough spots ... by the way, are you doing this for a real application - or just to learn more about the system? ... hope this helps ...

[waterboy 7]

Don't worry about that, I never learned how to give up. An annoyance to many of my co-workers And yes this is a live working system. I have brief time slots to make changes to it. Edited 11 Jan 2008 by waterboy

[Guest]

sorry but my tired old eyes can't make out much on that screen shot - even after I click it to enlarge it ... can you post the code (RSP file) for us to look at? ... if not, try posting several screen shots instead of one long one ... usually those are easier to read ... offline until tomorrow ... Edited 10 Jan 2008 by Ron Beaufort

[waterboy 7]

I re-posted the graphics, clicking on the ladder makes it clean enough to see now.

[bikerdude 0]

waterboy, Your block x-fers appear to be correct. The error seems to indicate that when the analog module responds to the read request, the data is being corrupted along the way for some reason. The path that the data takes is along the chassis backpane. From your Rack,Group,Slot addressing it appears that the module is really close to the processor. Are there any other high voltage / high noise module types in the adjacent slots? I only ask because there is a warning in the manual to avoid that. There is another warning in the manual about determining if power supply wattage is great enough to supply all of the installed modules. Personally I have never ran into a situation where a full chassis overloaded the power supply. But they put that warning in there for a reason. So, a full chassis that has it's power supply strained to the max may cause backplane comm. errors? I see that this output is described as a VFD signal. Does your analog cable have the shield properly grounded (earthed) on the controller side only? I ask because these analog cables can pickup quite a bit of noise in a cabinet with a VFD. Noise and or ground loop problems in the analog cable may cause errors within the output module, which may cause the module to processor communication errors. Try this in order: 1.Check for a clean tight PLC chassis earth ground. 2.Check for a clean tight analog cable shield connection to the same earth connection on controller end only. 3.Check that power supply wattage is greater than required for all the installed modules. 4.Pull the module & clean the backplane connector with a pencil eraser if possible. 5.Move the module to another slot that doesn't have nearby hi energy usage modules if possible. Good luck BD

[Guest]

I agree with bikerdude ... your Block Transfers seem OK ... what addressing mode are you using in this chassis? (two-slot, one-slot, or half-slot) ... note: check this on the SWITCHES tab of the Processor Status screen ... specifically, do NOT check the setting in the "IO Configuration" feature ... what other modules do you have installed in this chassis? ... please list CATALOG numbers for ALL of them - even if they don't use block transfers ... finally ... is there any reason why you can't post your .RSP file? ...

[Bill Linne 0]

Thanks everyone for your input. "Waterboy" and I work together (he is off today). I think the power supply may be the issue. We are expanding the plant, and recently swapped an 8-slot chassis out to a 12-slot (to support installation of another 250 HP pump). All fine up until two days ago when we had a shutdown opportunity and actually populated the chassis with the four new modules. Two of them are analogs, one input and one output. The other two are digital, one in and one out. They have nothing wired to them as yet. Next week I have another shutdown opportunity, and intend to install a 1771-P7 power supply in place of the smaller, slot-occupying 120-volt supply in there now. (Which brings to mind a question: Can the P-7 be installed, connected, and powered-up while the PLC is being powered from its existing power supply? (Essentially operating them in parallel.) I know multiple power supplies can live in one chassis together, so why not one in-chassis and one off-chassis? Then we could pull the in-chassis supply without shutting down. (It is usually possible to get a shutdown each month for a few hours, but this is to satisfy my curiosity, really.) Thanks again for all the ideas. We will certainly advise the outcome. If the P/S does not do the trick, we'll post the logic. It is very basic, and worked fine for years until the situation I described above. Then the BTR's of the existing and new A/O modules both started intermittently erroring. Sometimes Done, sometimes Error. No consistency or pattern. I understand we don't even need that logic, but it should work, nonetheless. Bill

[Guest]

NO ... please don't try this ... basic idea: the power supply does more than just supply power ... it also communicates (at a very rudimentary level) with the processor ... (quick basic example: “hey, processor, we’ve just lost the AC line feed out here, start shutting down the system, I’ll try to keep feeding power for a few more seconds.) ... key point ... there is a jumper (marked “Y/N”) located on the chassis backplane behind the processor ... it basically tells the processor whether to expect the power supply to be physically located INSIDE the chassis - or OUTSIDE the chassis ... if that jumper is not set correctly the processor will absolutely GO NUTS until the jumper position is fixed ... you’re not going to be able to reset the jumper while you’re up and running ... hope this helps ... sure would like to see that code - and the layout of the I/O modules ... Edited 11 Jan 2008 by Ron Beaufort

[Bill Linne 0]

Thanks, Ron. I knew you'd have the answer to that. I now remember the jumper, as I have a couple of the P-7's presently in service. Your explanation also explains (I think) the communication cable between power supplies when two of them live in the same chassis. I'm home now and pooped. Been one of "those days" (a fitting conclusion to one of "those weeks"!). We'll make it a point to post the other details asap. Regards, Bill