Created Date: October 13,2016

Created by: CRMWD

Hi all,

So I have a float that I would like to store in two single-integer registers. That is to say, I want to store the low word in one integer and the high word in the next. This is necessary because the master is reading the from registers 400712-400713 and changing it to look somewhere else is not really an option. I 've tried using the copy function every way it will let me, but it always turns it into a regular integer. Same thing for the math function. Alternatively, if I could remap a DF to a different ModBus address that would work fine too, but see no way to do this.

Any ideas on how to accomplish either of these things?

Thanks in advance!

Created Date: October 14,2016

Created by: CRMWD

The math function converts it to integer when you save the output in a DS or DD. I'm not concerned too much with the decimal, but the problem is that the master is expecting it in float format, and because it's Modicon it can't even query for the extended decimal range that the floats live in (even if changing that program were feasible). It's just so strange to find a PLC that doesn't let you just take 32 bits from one register and drop them into two others without a conversion.

I'd briefly considered a subroutine that manually does a floating point multiplication with relay logic on 32 C registers, but I wouldn't know where to begin with that.

Created Date: October 17,2016

Created by: g.mccormick

I was confused, I didn't konw you were attempting to keep it in floating point values.

Can you

1. Copy DF to DH

2. Unpack copy DH to C0-C31

3. Pack Copy C0-C15 to DS712

4. Pack Copy C16-C31 to DS713

Will that work?

Created Date: July 05,2018

Created by: CRMWD

I was confused, I didn't konw you were attempting to keep it in floating point values.

Can you

1. Copy DF to DH

2. Unpack copy DH to C0-C31

3. Pack Copy C0-C15 to DS712

4. Pack Copy C16-C31 to DS713

Will that work?

Sorry I'm replying 2 years late, I found an altogether different (and nutty) solution that doesn't rely on the CLICK's internal functions. Anyway, the problem here is that when you copy from DF to DH, it doesn't do a 32-bit byte copy but tries to convert it into an integer-value 16-bit hexadecimal. I am truly baffled that an otherwise competent device with some interesting advanced features lacks literally the simplest data handling feature of any PAC/PLC, which is a straight bit-copy. I'd be happy with any conversion pathway if it worked, but there simply isn't one.

If anybody is interested, though, there is a VERY hacky solution to making this work. It requires a bi-directional RS-485/232 serial converter OR another ethernet-enabled PLC/PAC with free registers that it's okay to write to. In the former case, you can connect your two serial ports together (assuming you 're not already using one or both ports for something else OR you 're the master device on that network) and do a SEND block to yourself from your RS-485 port to your RS-232 port. So you can SEND, say, DF212 on port 3 (for an ethernet-enabled model, port 2 for others) to slave device 2 (or whatever) at address 400712. This actually works, but it's really messy. This particular need is no longer an issue for me, as we ended up restructuring our communications in a way that happened to allow me to simply write my values directly to the remote data aggregator instead of waiting on it to read the values from the remote PLCs.

Thanks!