Our full technical support staff does not monitor this forum. If you need assistance from a member of our staff, please submit your question from the Ask a Question page.


Log in or register to post/reply in the forum.

Call argument unexpectedly change value


Geir Aug 27, 2014 08:01 AM

I have now struggled for hours understanding why my LongAddress(2)-variable keeps changing value. Gradually I have cut away all my code, realizing that the value keeps changing just by calling the subroutine.

LongAddress(2) is supposed to contain the value 117955231 which I set manually from the LoggerNet Connect Screen (Table Monitoring). What happens the next program execution is that the value change to 117955232.

It seems like the 3 least significant bits are rounded. If I keep increasing the value some units, I end up with these steps:
707DAA0 (117955232)
707DAA8 (117955240)

Strangely it is no problem storing the value 9F (159) in the variable, which indicates a resolution-related problem. This makes little sense for a Long-variable.

I am using a CR850 with OS Version: CR800.Std.27 and LoggerNet 4.1.0.16


Public PTemp, batt_volt

Public LongAddress(2) As Long
Public PrimaryVariable As Float


Sub ReadPrimary ( Adr As Long(2), PV As Float )

EndSub


'Main Program
BeginProg
  Scan (5,Sec,0,0)
    PanelTemp (PTemp,_50Hz)
    Battery (batt_volt)

'      LongAddress(2) = 117955231
      Call ReadPrimary ( LongAddress, PrimaryVariable )

  NextScan
EndProg


jtrauntvein Sep 8, 2014 06:30 PM

According to the CRBasic help, subroutine parameters appear to be passed by reference rather than by value as you expect. Consider the following extract:

"Changing an argument's value inside the Subroutine changes its value in the calling procedure."

A CRBasic Function will pass its values by value.


Geir Sep 9, 2014 06:28 AM

I'm aware that CRBasic subroutines are working with referenced arguments. Either way I expect the variable(s) to remain unchanged when calling an empty subroutine.

My workaround have been to left-shift my useful data one byte to keep away from the least significant byte that is rounded/truncated whenever I call the subroutine. Not very elegant, but it works.

It seems like I might have stumbled upon some kind of a firmware error which mess up memory in a way which influence the least significant bits in my Long(2) variable.

Please try running my code on a CR850 on your own and set the LongAddress(2) to the 117955231 in LoggerNet table monitoring. It should not change since there is no code for changing the variable, but the value does change for me.


RJT Sep 9, 2014 01:30 PM

If you change the following statement in your program

Sub ReadPrimary ( Adr As Long(2), PV As Float )

to

Sub ReadPrimary ( Adr As Long, PV As Float )

should resolve the problem.

Log in or register to post/reply in the forum.