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. . .

No idea on the first on.



The BT block gives you structured data and mnemonically addressable bits. Thats all. Enhanced processors support the BT block. But the N block should work just fine, ultimately it all the same in memory.


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

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...

Greetings Waterboy ...



that’s handy because that’s EXACTLY the hardware that I use in my classes ...



so far so good ...



most programmers (for better or for worse) don’t use the status that the BTR brings back from the module ... if you’re not going to actually USE the data for anything (alarms, etc.), then it doesn’t hurt to just cancel out the operation of the BTR rung ... many programmers use an AFI (Always False Input) for this ...



the first thing to check is ALWAYS to make sure that there is no “overlap issue” in the memory which is assigned to the OFE module with ANY other component or instruction ...



there are TONS of the older N-type control blocks still being used out in the field ... (that’s one reason that I still cover them in my classes) ... still, if I were setting up a “new” system, personally I’d use the BT-type blocks ... they’re easier for most technicians to understand - and much harder for them to inadvertently “mess up” ...



I can’t say for sure without seeing more about your system, but that approach is probably not going to “fix” anything - it’s probably just going to make the “error bit problem” MORE evident ...



as long as that’s done correctly, there’s no reason why it shouldn’t work ...



yes, there’s a tradeoff ... remember that you’re telling the processor to TRANSFER (move) a BLOCK (a sizeable chunk) of data from the module into the data table ... that operation takes up a certain finite amount of time ... the more often you do it (as by using the /EN bit) then the more traffic you’re putting on the chassis backplane ...



there must have been a “failure to communicate” somewhere along the road here ... you should be able to use the “IO Configuration” feature in RSLogix5 to produce the data that you need ...



that’s fishy ... those statements make it look more and more like a “memory overlap” problem ... suggestion: post your code and let us take a look ...



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 ...

I have created all new memory for the contol blocks and spaced them far apart



by hitting with more frequency I imagine?



Since I could be hitting more than one BTR/BTW at the same time, could that contribute to the error?



That makes sense, but is is a real concern? we don't have anything that would be timing dependent



As you can see in the attached graphic, that isn't the case, the raw min and max get written to the Data file (N9) and nothing gets written to the control file (N17), I put the 4095's in there at the instruction of Rockwell. They were all Zeros.
[attachmentid=5763]
[attachmentid=5764]
[attachmentid=5765]
[attachmentid=5766]
[attachmentid=5767]



if thats true, the 4095's I placed there would get overwritten but whatever overlapped it.


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.

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 ...

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

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

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? ...

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

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 ...

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