GX IEC DEV. Calculation 32bit problem.

Hey!

Working with an FX1N
And trying to calculate

total = DINT
tempA = DINT
tempB = DINT
sens = D13 INT (0-1000)

M8013 -||- [DADD_P]
sens _int_to_dint_ + tempA = tempA

[DMUL_M]
tempA * 12 = tempB

[DDIV_M]
tempB / 60 = total


this is how i want it to work.
But there is wrong with my variables.
on the dmul/ddiv output it wants 64bit! how can i then use it as input on the other?!

Thanks for any help!
Hope you guys understand what im trying to do.

Mekme
I am not sure about this on an FX1 but for an A series Mitsi the 64 bits consists of one DINT for the result and one DINT for any remainder or overflow. I normally create a scratchpad of 4 DINTS (or 8 words) to hold the intermediate results of calculations and only move the result into the required variable once the calculation is completed.
Andybr

To be able to work with DMUL i have to define the output variable (in this case tempB) to

tempB = Array of [0..1] DINT

compiling. yeah the DMUL is ok.
but tempB isnt usable as input on DMUL

Any tip regarding that?

I dont understand your tip for sure. Should I define the variables as array with word? is it possible to calculate with that?

Best Regards
Martin

Martin
I would not normally put these elements in an array but I do not see a problem with this. The DMUL instruction needs the address of the first element of your array. Not the name of the entire array.
Andybr

I cannot test it but here is what I would start with:

tempa = sens+tempa
tempb = tempa*12
total = tempb/60
in other words
total = (sens+tempa)*12/60 = (sens+tempa)/5

d100 sens (use even address and make sure next one is not used)
D101 zero (to be used as higher 16 bits of the SENS)
d102, d103 tempa
d104, d105,tempb
d106, d107, d108, d109 temp (this is 4x16=64 bit destination used for calculation)
d110, d111 result (32-bit)

MOV k0 d101 ; keep this one zero (make SURE it's zero)
DADD d100 D102 D102 ; tempa = sens + tempa
DMUL D102 K12 D106 ; temp = (sens+tempa)*12
DDIV D106 K60 D106 ; temp = (sens+tempa)*tempb/60
DMOV D106 D110 ; total = (sens+tempa)*tempb/60

or shorter version:
MOV k0 d101 ; keep this one zero (make SURE it's zero)
DADD d100 D102 D102 ; tempa = sens + tempa
DDIV D102 K5 D106 ; temp = (sens+tempa/5
DMOV D106 D110

(hint: just make sure to keep track of result size...)

Yeay! Thanks alot Panic!

Now its working fine.

But here it comes another problem..

I have an FLUKE Loop Calibrator connected to the 2of the analog inputs on the 4AD Module

I put it to 20mA and start running the totalizer.
yeay same value on both totalizers.

But the problem is, it will not end up as the same on both totalizers when i step around for some time between 16-20mA


Seems to be some "cycle-issue" ?
Anyone knows what I can do to prevent this huge failure! Cause the endresult is not the same on both totalizer but the same signals are sent to it.

The endproduct is with an coriolis meter with Qv and Qm.

Sorry for my strange english =)

Hi Mekme.

Have you configured your card as a 0-20mA or 4-20mA?
You can adjust the offset and/or gain in the buffermemory
Se pic below.



Hope this solves your prob.


Best regards

Dariusch

Mekme

I would check the settings for the analogue channels to make sure that they are identical but even then you will never get the two channels to give you exactly the same totals for any significant period of time. There will always be very small differences of accuracy, linearity and response time between the two channels which will result in small errors which will be integrated over time to generate a noticeable difference. If everything is set up correctly this difference should be small but you should not get too fixated on something that you will never be able to resolve.

Aha. Maybe i can get a more precise endresult if i use the pulseout on the coriolis? What do you think of that? Counting the pulses instead of calculating the ad.

Mekme
I would normally use the pulsed output if one was available. You could also use the pulses to calculate rate and save the analogue inputs if you wanted to. The only issue with this is that the response time becomes long if you need to monitor very low flow rates.