Where Do 'local' Variables Go?

[patrickokeeffe]

Using DAQFactory Express 5.87c Build 2050 on Windows 7 Ent. x64 SP1,

 

Following the instructions of the Serial Guide, section Poll / Response and streaming data, produces errors for me. I successfully followed the previous section, Creating a protocol to accept non-polled data, but as soon as I try to reference local variables, 'C1000' errors occur.

 

This version of my protocol file works just fine (it's largely boilerplate):

U,MWE_LI840A
I,Input,0,input,string

ENDIO

F,Poll,0
function Poll(string out, until)
// this function will poll the port with given string and read
// the response until the given character.  Returns NULL (empty)
// if there is an error

if (argc < 2)
   throw("Invalid number of parameters")
endif
private string in
try
   // lock the port
   if (!LockPort())
      throw("Unable to lock port")
   endif
   // clear anything pending
   Purge()
   // output our string
   Write(out)
   // and read until the eol:
   in = ReadUntil(until) 
   // release the port
   UnlockPort()
   // and return the response
   return(in)
catch()
   // error occured
   UnlockPort()
   throw()
endcatch
// return NULL to indicate error.  This should never happen
// because of the throw() statement above
return(NULL)

ENDIO

E,OnLoad
local streamflag = 0

ENDIO

E,OnUnload

ENDIO

E,OnReceive

if (1) //streamflag)
   if (strIn == Chr(10))
      private string datain = ReadUntil(10)
      Channel.AddValue(strDevice, 0, "Input", 0, datain)
   endif
endif


ENDIO

E,OnSend

ENDIO

But when I de-comment the `streamflag` reference in function `OnReceive`, C1000 errors begin:

U,MWE_LI840A
I,Input,0,input,string

ENDIO

F,Poll,0
function Poll(string out, until)
// this function will poll the port with given string and read
// the response until the given character.  Returns NULL (empty)
// if there is an error

if (argc < 2)
   throw("Invalid number of parameters")
endif
private string in
try
   // lock the port
   if (!LockPort())
      throw("Unable to lock port")
   endif
   // clear anything pending
   Purge()
   // output our string
   Write(out)
   // and read until the eol:
   in = ReadUntil(until) 
   // release the port
   UnlockPort()
   // and return the response
   return(in)
catch()
   // error occured
   UnlockPort()
   throw()
endcatch
// return NULL to indicate error.  This should never happen
// because of the throw() statement above
return(NULL)

ENDIO

E,OnLoad
local streamflag = 0

ENDIO

E,OnUnload

ENDIO

E,OnReceive

if (streamflag)
   if (strIn == Chr(10))
      private string datain = ReadUntil(10)
      Channel.AddValue(strDevice, 0, "Input", 0, datain)
   endif
endif


ENDIO

E,OnSend

ENDIO

I'm following the examples verbatim here! What am I doing wrong?

 

[AzeoTech]

Most likely OnLoad isn't getting called after you make the edit.  You have to reinit the comms to get OnLoad to run.  It doesn't run after every edit (for some good reasons).  So, do:

 

device.myDevice.initComm()

 

at the command alert after making any changes to OnLoad.

 

Also, I generally don't recommend using custom protocols unless you want to reuse across lots of documents.  Its much easier to write a simple sequence to monitor the serial port for streaming data.  

[patrickokeeffe]

OK, I think I've ruled out that explanation: the same errors occur after quiting & re-opening the document, and after entering `Device.mydevice.InitComm()` into the command window. How would I continue to troubleshoot this? Since `onReceive` is part of custom protocols, I can't really address this problem by switching to sequence code.

 

I wouldn't bother with a custom protocol except this project requires code be maintained under version control, and we use several of these devices in somewhat-transient DAQ setups.

[AzeoTech]

While not the problem, the explanation still applies.  I'd put a ? "Loading" at the top of your OnLoad just so you can see when that function is called.

 

Anyhow, we've found the problem.  It was introduced when we added the ability to do transient variables in objects.  Anyhow, a fix will be in the next update.  In the meantime, you can simply change the declaration to:

 

local transient streamflag = 0

 

and it should work for you (and continue to work in the next release).

 

Thanks for pointing this one out!

[patrickokeeffe]

Using `local transient` for the declaration has resolved my errors - nice & easy workaround. Thanks for your help!