The first thing which occurs to me is that this might be another manifestation of bug 2520 (after all, not a bug, but
logical tcl behavior). readserial() just uses TCL_GetVar.

As for \0's, a side effect of C \null string termination either in tcl or in the scilab glue: 

-->TCL_SetVar("a",ascii([1 0 2 3]))
 ans  =

  T  

-->ascii(TCL_GetVar("a"))                
 ans  =

    1.  


However there should be workarounds, otherwise the serial toolbox is simply not fit, no excuses. I'd have a look under
the tcl command "binary", and would perhaps resort in the serial toolbox to pass the data as numeric array (inefficient
but failsafe). As already written privately to the OS, I just need some time ahead for it, I'll be travelling next
week.

Enrico
      

I have opened a com port with 'mopen' and send the same kmd with the 'mfprintf'

fd=mopen('COM5','r+');
(i wondert that mopen opend a comport with this handle(19200,0,8,1))

mfprintf(fd,'%s',ascii(kmd)) (kmd look at Steps to reproduce the bug)

I get the same kmd-vector on my second PC, but the ascii(0) problem still there.

mfprintf sends nothing after ascii(0)

like:

kmd=[109 112 102 205 204 140 63 205 204 140 63 205 204 140 0 0 63...
205 204 140 63 205 204 140 63 16 3];

after: mfprintf(fd,'%s',ascii(kmd))

i get just [109 112 102 205 204 140 63 205 204 140 63 205 204 140]
      

(In reply to comment #2)
> I have opened a com port with 'mopen' and send the same kmd with the 'mfprintf'
> 
> fd=mopen('COM5','r+');

that might be a windows only contraption , i.e. not a solution, if it ever seems to work.

> mfprintf(fd,'%s',ascii(kmd)) (kmd look at Steps to reproduce the bug)
> 
> I get the same kmd-vector on my second PC, but the ascii(0) problem still
> there.

most likely also \0 terminated C-like strings here too. Anyway, that is another route.

As for the TCL way, I'm thinking at a workaround like this (to be tested yet)

function result=writeserial(h,buf)
   if ~exists("buf","local") then 
      TCL_EvalStr("set writeresult [catch {flush "+h+"}]")
   else
      TCL_EvalStr("set writeresult [catch {puts -nonewline "+h+..
                  " [binary format c* {"+mprintf(ascii(buf),%d)+..
                  "}]; flush "+h+"}]")
   end
   result=-eval(TCL_GetVar("writeresult"));
endfunction

TODO is to test it, to figure out the solution for setserial (with binary scan, perhaps), to repackage the toolbox...
      

Correction:

function result=writeserial(h,buf)
   if ~exists("buf","local") then 
      TCL_EvalStr("set writeresult [catch {flush "+h+"}]")
   else
      TCL_EvalStr("set writeresult [catch {puts -nonewline "+h+..
                  " [binary format c* {"+msprintf(" %d",ascii(buf(:))')+..
                  "}]; flush "+h+"}]")
   end
   result=-eval(TCL_GetVar("writeresult"));
endfunction


And for readserial something along the lines of:

function buf=readserial(h,n)
   if ~exists("n","local") then
     N=serialstatus(h); n=N(1)
   end
   TCL_EvalStr("binary scan [read "+h+" "+string(n)+"] c* ttybuf")
   buf=ascii(TCL_GetVar("ttybuf"));
// convert signed to unsigned chars here??
endfunction


But I have nothing to test it on at the moment.
Btw, I have assumed format c*, since I'm not awae of serial formats wider than 8bits.

Enrico
      

(In reply to comment #4)
Hmm... think I have to describe my kmd-vector.
It consists of a string convert to ascii. ( the first three numbers and the rest are axis positions).

For example: 

kmd=[uint8(ascii('mpf')) uint8([205 204 140 63 205 204 140 63 205 204 140 ...  0 0 63 205 204 140 63 205 204 140 63 16
3])];
// the axis position is a ieee754 format 
//A=ftoieee754(1.1) <---- ftoieee754 is a handcoded function
//A= 205 204 140 63
Now I have to send the kmd to my real-time-OS. If the rtos read the kmd-vector it must the same as I send it.


>       TCL_EvalStr("set writeresult [catch {puts -nonewline "+h+..
>                   " [binary format c* {"+msprintf(" %d",ascii(buf(:))')+..
>                   "}]; flush "+h+"}]")

in the kmd-vector are the first three numbers ascii-coded and at this line it will be coded back. Ascii([109 112 102
205 204 140 63]) try to code back to mpf and the axis to ascii(). (type string '%s')
I tried to replace '%d' with '%s' but i get a result = -1


> And for readserial something along the lines of:

>    buf=ascii(TCL_GetVar("ttybuf"));
The rtos send at the end 'Transmission OK'/'Transmission FAULT' in ascii-code (at the beginning mybe sends position
coordinates )
for example:
Transmission OK =>84 114 97 110 115 109 105 115 115 105 111 110 32 79 75

and with 'buf=ascii(TCL_GetVar("ttybuf"));' the numbers will be code to ascii back
for example: the 84 will be code back to [56 52].
At the first version of the readserial function I got the 'Transmission FAULT' sentence not the ascii-code after
reading the port.

I know that is really difficult and I thank you again for the help.
      

(In reply to comment #5)
> (In reply to comment #4)
> Hmm... think I have to describe my kmd-vector.

Not really. My goal is to fix the functions so that any string of (8bit) characters is supported, irrespective of the
purpose.

> It consists of a string convert to ascii. ( the first three numbers and the
> rest are axis positions).
> 
> For example: 
> 
> kmd=[uint8(ascii('mpf')) uint8([205 204 140 63 205 204 140 63 205 204 140 ... 
> 0 0 63 205 204 140 63 205 204 140 63 16 3])];

wait - writetoserial expects a string argument. In principle I could make it accepting a numeric array as well, and
silently avoid to recast it to numbers, depending on the type of the argument. However, in the attempted fix (provided
it ever works) I gave above, I assumed that kmd was a string. Remember that ascii(number)=string and
ascii(string)=number.

> and the axis to ascii(). (type string '%s')
> I tried to replace '%d' with '%s' but i get a result = -1

no, %d. I want numbers there. I want that the command passed to TCL_EvalStr
looks like


puts -nonewline file123ab678 [binary format c* {205 204 140 63 205 204 }]

> > And for readserial something along the lines of:
> 
> >    buf=ascii(TCL_GetVar("ttybuf"));
> The rtos send at the end 'Transmission OK'/'Transmission FAULT' in ascii-code
> (at the beginning mybe sends position coordinates )
> for example:
> Transmission OK =>84 114 97 110 115 109 105 115 115 105 111 110 32 79 75
> 
> and with 'buf=ascii(TCL_GetVar("ttybuf"));' the numbers will be code to ascii
> back
> for example: the 84 will be code back to [56 52].

If there are \x00's in this string, TCL_GetVar will see them as end of string. That's the point. If by chance some
sequence of bytes (where typically the first is>128) makes sense as multibyte character in the current encoding,
TCL_GetVar will try to render it as an exotic character, mangling the data. And if it flags a multibyte character, but
does not make sense, TCL_GetVar will replace it wit - - - or ? ? ?, still bad.

That's why readserial should be rewritten, IIUC as above - but I have to test it when I have some time; as above, it
might very well be broken.
      

Yes you're right with the writeserial (at Comment #6), I'm sorry . The solution that you written in Comment #4 works
and I can transmit the data without misstakes.

I recognised that the function ascii() and char() have some problems with 0 too.

ascii([84 114 97 0 110 115 109])
ans = Tra

//but the length of ans still 7

k=ascii(ans)
k = 84 114 97 0 110 115 109


The same with the function char():

char([84 114 97 0 110 115 109])
ans = Tra
      

(In reply to comment #7)
> Yes you're right with the writeserial (at Comment #6), I'm sorry . The solution
> that you written in Comment #4 works and I can transmit the data without
> misstakes.
> 
> I recognised that the function ascii() and char() have some problems with 0
> too.
> 
> ascii([84 114 97 0 110 115 109])
> ans = Tra
>
> //but the length of ans still 7
> 
> k=ascii(ans)
> k = 84 114 97 0 110 115 109
> 
> 
> The same with the function char():
> 
> char([84 114 97 0 110 115 109])
> ans = Tra

That is a (display?) bug of scilab 5, I guess once more because of the use of C string functions rather than Fortran
for the display. In 4.1.2

 -->ascii([84 114 97 0 110 115 109])
 ans  =

 Transm   

-->ascii(ans)
 ans  =

    84.    114.    97.    0.    110.    115.    109.  

Would you be so kind to open a separate bug for this?
Enrico
      

> At the first version of the readserial function I got the 'Transmission FAULT'
> sentence not the ascii-code after reading the port.


Would you try out this one, which has some chance of working?

function buf=readserial(h,n)
   if ~exists("n","local") then
     N=serialstatus(h); n=N(1)
   end
   TCL_EvalStr("binary scan [read "+h+" "+string(n)+"] c* ttybuf")
   buf=ascii(evstr(TCL_GetVar("ttybuf")));
endfunction


If it does, when I can I'll post a corrected toolbox. Perhaps with tcl variables in a protected namespace, or some
other improvement.
Enrico
      

(In reply to comment #9)


> Would you try out this one, which has some chance of working?
> 
> function buf=readserial(h,n)
>    if ~exists("n","local") then
>      N=serialstatus(h); n=N(1)
>    end
>    TCL_EvalStr("binary scan [read "+h+" "+string(n)+"] c* ttybuf")
>    buf=ascii(evstr(TCL_GetVar("ttybuf")));
> endfunction

The readserial works and shows the rigth sentence until a zero. (bug of ascii)
      

(In reply to comment #10)

> The readserial works and shows the rigth sentence until a zero. (bug of ascii)

you mean: it retrieves the string including the zeros [please check with ascii(readserial()) ] but the string is not
displayed beyond the zeroes because of the *display* bug, correct?
      

(In reply to comment #11)
 but the string is not displayed beyond the zeroes because
> of the *display* bug, correct?

besides, bug 3831 is solved now       
      

For the record, I've repackaged the corrections as Serial-0.2 and put it on
http://www.weizmann.ac.il/home/fesegre/scistuff.html. The help files are still in 4.x format, as long as I cant't
figure out how to build help in scilab 5 [nor I'm sure that the process works anymore with 4.1.2]; should I succeed,
someday I might include both help formats in the package, and builder/loader working for both versions.
I don't close the bug yet as I'd like to test the functions once more, which I might do as soon as someone drops on my
table a serial instrument whatsoever.
Enrico
      

As this bug refers is not a Scilab bug, I set it to WONTFIX.