analog data help

L35 Compact logix plc with Numatics G3 Fieldbus IO connected by ethernet. Fieldbus IO consist of 9 digital input modules, 3 digital output modules, and 1 analog module. The Numatics shows up in the RSLogix 5000 as 32 bit words. So each word has 4 rows (bytes) of 8 bits, the analog module is a 4 channel module, each channel uses 2 bytes. So the 1st analog input uses the last byte of word 11 and the 1st byte of word 12, to make up the 16bits that contain the value of the analog input. So how do I get these two bytes from 2 different words and have usable data. I would guess that 1 of the bytes is "most sig" and the other is "least sig", I just don't know how to put them together, can anyone help

Thanks
Travis

travish said:

L35 Compact logix plc with Numatics G3 Fieldbus IO connected by ethernet. Fieldbus IO consist of 9 digital input modules, 3 digital output modules, and 1 analog module. The Numatics shows up in the RSLogix 5000 as 32 bit words. So each word has 4 rows (bytes) of 8 bits, the analog module is a 4 channel module, each channel uses 2 bytes. So the 1st analog input uses the last byte of word 11 and the 1st byte of word 12, to make up the 16bits that contain the value of the analog input. So how do I get these two bytes from 2 different words and have usable data. I would guess that 1 of the bytes is "most sig" and the other is "least sig", I just don't know how to put them together, can anyone help

Thanks
Travis

Click to expand...

Welcome to the Forum!

I would look at the BTD Instruction, although there are certainly other ways of doing what you want to do. Have a look at it in Chapter 7 of the Instruction Reference.

http://literature.rockwellautomation.com/idc/groups/literature/documents/rm/1756-rm003_-en-p.pdf

Stu....

thanks,

Looks like that is what I need. I will try tomorrow and let you know how it worked.

Travis

No Problem. By all means let us know how it works out, and if you have any more questions or problems, ask away.

Stu....

OK, something did not work exactly right. I switched from INput #1 to input #2 just so both Bytes were in the same word. the input is and Turck RI360 it is a rotory sensor that send 0 - 10v, Verified it with my meter that this works. so 0v should be a count of zero, and 10v should be 65535 (thought I would see 32767, but I guess it is the 16th bit) looks like it never made it to zero or alll the way up to 65535. but I am sure that it really did because of the meter test. maybe over ethernet I don't have real good resolution because of some read/write time. anyway when watching the count in the plc i have seen the count momentarily jump way off then back again to continue counting. Do you think I did something wrong with the instruction or maybe some "noise" going on?



I going to post the program but it said that ".acd" was an invalid file type

Thanks
Travis

Your GRT/LES and MOV Instructions don't look right to me. Have another look at them.

Also, if you want to Post your Program File, Zip it first, or change the Extension to ZIP if it is small enough, and tell us you have done it when you Post it.

Stu....

Sorry for the confusion, the GRT,LES are how I determined that the input was not going full scale from Min to max. I am positive that the sensor is going to 0 and 10v. If I were having noise problems how would it show itself? My plc is sending a speed ref to a vector drive which is turning a wheel and the rotory sensor is feeding back the position to the plc. It is a relitivly cheap closed loop system,I need very little accuracy in the application. but I can't randomlly get a wrong signal. what I think I saw today was when the wheel was at roughly 350 degrees the signal momentarily went to like 270 degrees. I will try to better identify the problem tomorrow and post the program

thanks again

I agree about the logic not looking right. I thought you were having to take the bits from two DINTs and piece them back together as a SINT.

And, when capturing the data updated by the Numatics:

Instead of MOV, try CPS. If the bits are updated syncronously, you want to copy them synchronously. I am not sure if this will make a difference, but if you CPS the whole chunk, I think that is suppose to request a snapshot of the whole range at once, rather than in two separate MOV instructions which could be interrupted (occasionally and randomly) by an update of the data by the Numatics controller.

If the cable is shielded, and the shield drained properly at one end routed away from noisy motor and power leads. it is likely that you are picking up bits during the update of the input data due to asynchronous update collisions so to speak.

What a poor way to report data via Ethernet I/P, you would think they would at least break on 32 bit boundaries so you could use a simple UDT to map them to raw units.

I strongly agree with Paul's suggestion to use the Copy Synchronous (CPS) instruction to an intermediate tag before doing anything with this data.

To deal with diverse data types that don't line up neatly on a 32-bit boundary, one good method is to perform a CPS to a SINT[x] array, so that all the data is laid out byte-by-byte. Then you can use ordinary COP instructions to move data by 1-byte, 2-byte, or 4-byte chunks into the proper Tags or UDT Elements.

This method is used extensively by the RA DeviceNet Tag Generator tool, if you want to see an example with complex data types.

Oh, and "noise" cannot generate corrupted data on a digital network. Well, it can, given enough time and probability, but you've got a better chance of finding yourself a bowl of petunias in a re-entry orbit.

OKie, I do have to get data from to different words for for input 1 I am currently using input 2 so both bytes come from the same word

I will try the CPS and let you know next week