S:1/15

[Guest Dark Dog]

I reviewing a ladder program for reading transmitter inputs.. there is a first pass instruction to a COP #N40:0; #O:4:0; 8 then it another rung COP #I:4:0; #N70:0; 8 Now N40:0 etc. is all zero's. My questions is why do the first instruction; the second rung copies the transmitter inputs to the file N70:0 etc. Do I really need it or am I missing something really basic. The input card is in slot 4, the rest are Digital I/O. SLC5/03 processor. and the program works fine.

[Guest JIMMY]

This is called indirect addressing. Another way is to use the BTR and BTW to read and write the analog values, but you still have to scale them. Also when using indirect addressing do not go up to the database and erase any unused addresses this will mess up your indirect addresses. good luck..

[Beryl 0]

It looks like to me that on the first pass. The program is writing 0's to all of the outputs and moving the input values into a storage location. Many reasons to write 0's on start up. "Start fresh" on powerup, initialize the program. By the way, Jimmy, I think you have confused INDEXED with INDIRECT addressing. The # in front of the address means indexed with uses the value in S:24 to offset the address. Happy Programming

[Guest Dark Dog]

Yeah realize writing all zero but but the card in an analog input....is this writing to the input registers of the card...is there something like that?

[Guest guest_Allen_Nelson]

Some SLC analog input modules, such as the 1746-NI8, require that the module be configured before it can recieve input information (or rather, before the input information will be understood correctly). Other modules, such as the 1746-NI4, don't require a configuration In the NI8's case, 8 words of data (if class 1) are sent to the OUTPUT address which corresponds to the slot. All zeros for an NI8 would mean ±10V, engineering units (i.e, -10250 to +10250) scaling, zero open-circuit state (irrelevant for voltage detection), no filtering on the input signal, and the channel is disabled (!!!???!!) Since the last is unlikely, you may have recieved some "default" logic by the person who programmed your SLC. This would be just some logic that is put in for every job, whether it is needed or not, so that, if it IS, or becomes needed, the assignment's already there. As for the copying of the I: to N70:, you aren't clear if this is done only on first-scan (like the configuration is), or if it's done every scan. My guess, and it's only that, is that the copy is done every time, and that a cross-reference would reveal that this is the only line of code where any I:4 address is used. The SLC will fault if an expected card is not in the slot that it's programmed for (there is a way around this, but not everyone knows it). It's not uncommon to map ALL inputs and outputs to internal data files, and then have just a few "mapping rungs". These rungs can be deleted, and simulation logic put in their place, writing to the N70:s. When you go to test your program, you don't have to worry about having the correct modules in the rack. The SLC doesn't fault, and you can watch the (simulated) process run. Allen ©¿©¬

[Guest Cal]

Could you explain this in a little more detail? I would like to simulate a client program in our lab (SLC5/05) and of course don't have the ability to setup the exact hardware configuration. I have tried disabling all the modules in the processor config, but when I download and try to go into run, I get an error about the configurations not matching. One thing that may be a problem is the use of RIO. How do you deal with the M files? You mention a work-around that not many people know about. Can you explain that? Do you know of any tech notes that discuss this? Thanks for any help you can provide!!!!!