| 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 <2012> 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 | Index | 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 <2012> 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 |
| <== Date ==> | <== Thread ==> |
|---|
| Subject: | Re: Problems sending \x0 with devGpib driver |
| From: | Dirk Zimoch <[email protected]> |
| To: | Eric Norum <[email protected]> |
| Cc: | [email protected], Andrew Wagner <[email protected]> |
| Date: | Thu, 08 Nov 2012 14:50:48 +0100 |
On 08.11.2012 05:56, Eric Norum wrote:
The convert routine is passed the parameters from the command table entry and if it wants it can get at a pointer to the entire command table entry so you can likely provide a single routine that will handle lots of table entries. You might be able to get away with having to write only a single convert routine for all the commands you need to send. Certainly a pain, though. I wonder if StreamDevice would work.
Yes.The problem is writeMsgString(gpibDpvt *pgpibDpvt,const char *str) from devGpib/devSupportGpib.c which does not have any length parameter.
The lower level asynOctet function write() as well as all implementations I have seen have (and use) a length parameter. StreamDevice uses this function and passes the correct length.
Do not use devGpib for any new project!
On Nov 7, 2012, at 8:49 PM, Andrew Wagner<[email protected]> wrote:Hey Eric, Thanks for the advice and commiserating. I already wrote a standalone C++ program to communicate with this thing and it took a little while to write the functions to append and strip \x0\x7 on/off of every string I sent/received from it. It really amazed me that they chose to start every command with \x0 since thats what the entire rest of the world has agreed means end of string. I was hoping to avoid having to write my own version of AsynIPPort just to deal with the \x0\x7 bytes. Cheers, Andrew