FPWIN PRO7 REAL to DINT conversion not working

[panasonicq]

I have been working on an existing project for some time now and restructured the whole program into POUs instead of a singular main. Everything works as the old version except for one conversion I need to graph the output, for some reason the REAL_TO_DINT instruction seems to not work at all (e.g. 127.4999 turns to 0 in the output). Anybody with any experience working with panasonic PLCs could point in the right direction?

 

[Jim3846]

Panasonic plc , no experience. So lets try something!
What if you used a move statement?
Maybe the move statement would just chop off the .4999 and leave you with 127?
Is there a real to string conversion? Then you could go from string to dint?

 

[L D[AR2P#0.0]]

Post a screen shot demonstrating the behaviour

 

[parky]

Panasonic is very much like Mitsubishi, It works in Mitsubishi without problems.
Just a few things are you using global tags if so then the data registers (Dint) take up two registers i.e. D0 + D1 (cannot remember what they are in Panasonic), same goes for the reals, be careful you are not overwriting one of them somewhere else. This is a common mistake as a Dint on a small number will only have values in the lower word of a double word. and if this is used elsewhere then it could be overwritten.
for example a DInt id D100 + D101, if either D100 or D101 was being used elsewhere as an Integer then it could be overwritten.

 

[panasonicq]

Hey jim thanks for the alternate approaches but unfortunately move throws an error due to typing an despite the real to string conversion working it exhibits the same behaviour when trying to convert the string to dint.

As per LDs request I have attached a couple screenshots of the behaviour. The leer_encoder block outputs the speed of the machine after reading an encoder, I am trying to convert this output to DINT to graph it on the HMI.

 

[panasonicq]

original behaviour in action

 

[panasonicq]

Panasonic is very much like Mitsubishi, It works in Mitsubishi without problems.
Just a few things are you using global tags if so then the data registers (Dint) take up two registers i.e. D0 + D1 (cannot remember what they are in Panasonic), same goes for the reals, be careful you are not overwriting one of them somewhere else. This is a common mistake as a Dint on a small number will only have values in the lower word of a double word. and if this is used elsewhere then it could be overwritten.
for example a DInt id D100 + D101, if either D100 or D101 was being used elsewhere as an Integer then it could be overwritten.

I was afraid of this since the previous engineer did mention having to play around with the registries to get the program to work previously, however I assumed since I was using ones that already worked Id be safe. Do you happen to know an effective way to check if there is any overwrite? Or would I have to go around on each POU to check?

 

[Jim3846]

Is there a string command where you can just grab the whole number put that value in a dint?

 

[drbitboy]

the string-to-dint is probably crashing on the decimal point, which cannot be part of an integer in ASCII, only optional +/-, then digits, maybe leading or trailing spaces.


but the real-to-dint behavior is odd*. are you sure VELOCiDAD_MAQ is not a double-precision, 64-bit floating-point value? I am pretty sure it is showing more digits than are possible for single-precision, 32-bit float.


* i.e. I mean odd as in strange; I don't mean odd as in not-even

 

[parky]

In Panasonic I don't know, however in Mitsubishi if you use a Real i.e. D0 + D1 when you do a cross reference it only shows D0 the same goes for DInt's.
Are these tags globals i.e. they have physical addresses. for example
Var_Global My_Tag D10 %M10 DInt in the global tag list.
If so then search for the tag (D10) this is the lower word of the DInt.

 

[panasonicq]

the string-to-dint is probably crashing on the decimal point, which cannot be part of an integer in ASCII, only optional +/-, then digits, maybe leading or trailing spaces.


but the real-to-dint behavior is odd*. are you sure VELOCiDAD_MAQ is not a double-precision, 64-bit floating-point value? I am pretty sure it is showing more digits than are possible for single-precision, 32-bit float.


* i.e. I mean odd as in strange; I don't mean odd as in not-even

I declared it as a real and the manual for the FP PLC series states it is supposed to be 32 bit. I have attached an screenshot of the declaration of the relevant variables.

 

[parky]

Try putting in another contact i.e. NOT K1 so the rung is not TRUE then try & force the DInt, also maybe change the Dint to somewhere that is not used (allow 4 words just in case Drbitboy is right, however, it does appear to be a 32 bit float (single precision).

 

[panasonicq]

Try putting in another contact i.e. NOT K1 so the rung is not TRUE then try & force the DInt, also maybe change the Dint to somewhere that is not used (allow 4 words just in case Drbitboy is right, however, it does appear to be a 32 bit float (single precision).

It does seem to be a problem with that particular registry, I declared a local unused variable just like you said and it the conversion goes through. However when trying to move that value it doesnt work. Might have to go around checking for overwrites.

 

[parky]

Move may only be 16 bit, is there a DMOV instruction i.e. move 32 bit, plus your moving it into the same register you had in the first logic so I suspect there is something writing to it.

 

[drbitboy]

Sorry about the 32- vs. 64-bit confusion, that .00002 is at the outer limit, but it is still within the mantissa.


I forgot and included the leading 1 when I looked at the number on the back of the envelope.

$ cat rd.f ; gfortran -o rd rd.f ; ./rd


      programrd
      implicitnone
      doubleprecisionxdouble / 135d0 /
      realxreal / 135e0 /
      integerireal
      equivalence (xreal,ireal)
      print'(1x,2F12.7,F12.5,Z12.8)',xdouble,xreal,xreal,ireal
      xdouble = xdouble + 0.00002d0
      ireal = ireal + 1
      print'(1x,2F12.7,F12.5,Z12.8)',xdouble,xreal,xreal,ireal
      end


Output:


  135.0000000 135.0000000   135.00000    43070000
  135.0000200 135.0000153   135.00002    43070001