ScilabSerialLib

Comment from ivan stanisheuski -- October 22, 2012, 02:35:28 PM    

Something is wrong in the use of the slReadArrayN function.
The examples.
-----------------
The use of the slReadArray function:

-->slClose(1);  
-->slMount(1);  
-->slConfig(1,57600,8,0,1); 
-->slOpen(1,4);  
-->slFlush(1);
-->xpause(1000);   
-->databyte=slReadByte(1,0);  
-->while databyte==-1,   // wait until the buffer begins to fill 
-->  xpause(100); 
-->  databyte=slReadByte(1,0); 
-->end;
-->in=slReadArray(1)
 in  =
 
         column  1 to 11
 
    32.    0.    5.    1.    9.    0.    24.    0.    16.    0.    30.  
 
         column 12 to 22
 
    0.    17.    1.    21.    2.    28.    0.    17.    1.    16.    1.  
 
         column 23 to 33
 
    22.    2.    11.    2.    8.    1.    2.    0.    0.    2.    14.  
  
-->slClose(1);

The reading is correct, i.e. the result is expected. The two-byte sequence 
(0..5......1..9......0..24.......0..16......0..30....) is clearly visible in which the 
lower bytes have to be 0...3, the higher ones have to be 0...255.

------------------------------------------
The use of the slReadArrayN function:
-->slMount(1); 
-->slConfig(1,57600,8,0,1); 
-->slOpen(1,4); 
-->slFlush(1);
-->xpause(1000);
-->databyte=slReadByte(1,0);
-->while databyte==-1,          // wait until the buffer begins to fill 
-->  xpause(100); 
-->  databyte=slReadByte(1,0); 
-->end;
-->in=slReadArrayN(1, 33)
 in  =
 
         column 1 to 9
 
    1.    3.    18.  - 1.043D+09    1.    1.    1.    0.    1.  
 
         column 10 to 18
 
    1.073D+09    1.    1.    1.    0.    0.    1.075D+09    10.    1.  
 
         column 19 to 30
 
    1.    0.    1.    2.    18.    0.    10.    1.    1.    0.    1.    4.  
 
         column 31 to 34
 
    24.    30.    29.    1.073D+09  
 
-->slClose(1);

The result as compared with the previous one is somewhat strange.

Comment from ivan stanisheuski -- October 22, 2012, 02:39:27 PM    

The other examples of the slReadArrayN function usage:
-->slMount(1); 
-->slConfig(1,57600,8,0,1); 
-->slOpen(1,4); 
-->slFlush(1);
-->xpause(10000);
-->in=slReadArrayN(1, 33)
 in  =
 
         column  1 to 10
 
    1.    19.    18.    96.    1.    1.    1.    0.    1.    1.073D+09  
 
         column 11 to 21
 
    1.    1.    1.    0.    0.    1.075D+09    10.    1.    1.    0.    1.  
 
         column 22 to 32
 
    2.    18.    128.    10.    1.    1.    0.    1.    4.    24.    30.  
 
         column 33 to 34
 
    29.    0.  
-->slClose(1);


-->slClose(1);
-->slMount(1);
-->slConfig(1,57600,8,0,1); 
-->slOpen(1,4); 
-->slFlush(1);
-->in=slReadArrayN(1, 33)
 in  =
 
         column  1 to 10
 
    1.    22.    18.    96.    1.    1.    1.    0.    1.    1.073D+09  
 
         column 11 to 21
 
    1.    1.    1.    0.    0.    1.075D+09    10.    1.    1.    0.    1.  
 
         column 22 to 32
 
    2.    18.    128.    10.    1.    1.    0.    1.    4.    24.    30.  
 
         column 33 to 34
 
    29.    128.  
 -->slClose(1); 

The results of the readings are not expected.

Comment from ivan stanisheuski -- October 22, 2012, 03:05:24 PM    

This comment has been deleted.

Comment from ivan stanisheuski -- October 22, 2012, 03:05:52 PM    

In addition, taking into account that input data contain noise (i.e. stochastic) the 
readings strangely coincide in many places.

Comment from AS Kr -- October 22, 2012, 03:08:45 PM    

The first value in the array determines the valid length of the answer.
In all cases above, you received exactly ony one byte (at position 2 in the array).

All other, following values are invalid.

BTW, did you check for overflows?


ASkr

Comment from ivan stanisheuski -- October 22, 2012, 03:27:12 PM    

This comment has been deleted.

Comment from ivan stanisheuski -- October 22, 2012, 06:25:18 PM    

No, I did not check overflows.
My first step in the use of the slReadArrayN function is exactly like I have used the 
slReadArray function.

Comment from AS Kr -- October 22, 2012, 10:45:48 PM    

Checked this again.
My upload contained a wrong version of "slLoadLib.sci".

Fixed it, but did not change version number.
Thanks for bug testing ;-)


ASkr

Comment from Jannsen Holger -- October 23, 2012, 08:33:22 AM    

In slLoadLib.sci you load the siseli.dll 19 times with one entry point. But there is a
limitation (see link in sclilab help):
Number of 'link' in a scilab session can be limited by the operating system. On Windows,
you cannot load more than 80 dynamic libraries at the same time.

Therefore i suppose to link the siseli.dll once with 19 entry points, like:

slFuncs(1,1)=link("siseli.dll",["init","version","mount","umount","check","config","open","close","sendb","senda","count","recvb","flush","recva","sendp","packs","packe","packc","recvan"],"c");

Comment from ivan stanisheuski -- October 23, 2012, 02:57:08 PM    

I found no errors in the use of the slReadArrayN function.
Nevertheless i'm going to test the reading latency.