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
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.
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.
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.