serial

[p.e]

Hallo .

I ask help please I am new to Labwindows and want to read hex values over the serial from a microcontroller,

I use the functions below and when the interface runs it give me the folloing error .

the error relates to the buf array which hold the 100 data points ,

I have checked the reference manual and the example shown is the same as I used in the function ,

Please help me with what is wrong in the function.(error shown in red)

Thank you very much

Peter Erasmus

Switzerland

 FATAL RUN-TIME ERROR:   "RS232_Exmple.c", line 35, col 25, thread id 0x00000874:   Out-of-bounds pointer argument (before start of array).

int CVICALLBACK RunCallback (int panel, int control, int event,
  void *callbackData, int eventData1, int eventData2)
{
 int buf;
 switch (event)
 {
  
   int n = 0;
   char buf [100];
  
  case EVENT_COMMIT:
   
   OpenComConfig (4, "COM4", 9600, 0, 8, 1, 110, 20);  // Open and configure comport
      n =ComRd (4,buf,100);
   PlotY (panelHandle, PANEL_GRAPH, buf, 100, VAL_CHAR, VAL_THIN_LINE,
       VAL_EMPTY_SQUARE, VAL_SOLID, 1, VAL_RED);

     
   break;
   
  case EVENT_RIGHT_CLICK:

   break;
 }
 return 0;
}

[mvr]

The ComRd() statement looks ok to me. 

In your  OpenComConfig() set the last two values to 512.  They are the buffer queue sizes and the values you are using are probably not being accepted.  Most likely the OS will bump them up that high anyway.

You probably want to move the OpenComConfig() statement outside of the callback.  This way you will not need to open the com port for each execution of the callback.  Also I do not see where you are closing the com port, so if the callback executes more than once you are going to have a problem.

After the call to ComRd() check that n =100 before calling PlotY() or change the number of points in the call to PlotY to be "n", this will avoid trying to print data that is not in the buffer.

Since you open the com port and then read it right away, there is a good chance that no data is present in the input queue.  You really need the port to have been open for a while before trying to read the data.  You can set a timeout period for ComRd() calls, but calling ComRd() with long timeouts can cause your program to act like it is hung while it is waiting for ComRd() to return.

You might want to check the return code for OpenComConfig() to make sure there are no problems there, should be zero if no error occured. 

Message Edited by mvr on 08-14-2006 04:12 PM

[mvr]

And I am completely blind today, you have buf defined twice, once as an integer and later in the function as char buf[100].  I am sure you want to remove the first definition of buf.

[p.e]

Hallo mvr.

Thank you for your advise on the use of the functions, I am also blind I did not see that

i made the mistake of declaring buf twice.

I however have the question also I want to send intergers from the microcontroller ,but the serial read only

chars therefore I will have the interger in 2 array elements how do i merge them to be one int again to a control

Thank you very very much

Peter

Switzerland 

[mvr]

There are lots of ways to convert the data to integer format but if the data is in the format of a little endian (intel format) system you can just declare a pointer of the right type and point to your data buffer.

for example if you are using a 16 bit micro:

short iPtr; // pointer to 16 bit signed integer

bytesRead=ComRd(port, buffer, count);

iPtr=(short*)buffer;

now iPtr[0] points to the first integer in the buffer.

The number of integers in the buffer can be found from integerCount=bytesRead/sizeof(short)

If the micro is big endian you will need to do some byte swapping on the buffer before accessing the data.  Post here if you need help with that. 

[p.e]

Hallo mvr

Thank you I will post here as the micro is a 8 bit controller and high - low byte order,

I am working on this only in the evenings as I try to learn C and labwindows as a part time study to improve myself.

I removed the unnecessary definition (int Buf) from the code however the error remains telling me that it is a out of bounce pointer before array  as shown in the first post,

If you close the com port after the reads do you have to configure it again before the ComRd() is used again.

I appreciate the help very much Thank you very much.

Peter

Switzerland

[mvr]

If you close the com port, you have to open it again before using it.  You do not have to us OpenComConfig(), you can use OpenCom() but there really is not benefit to doing it that way.

If you are doing a lot of serial I/O leave the port open.  You can open and close the port as part of your main() routine.  If you only use it once in a while, it is not an issue to open and close it from inside the callback function.

I don't think the problem you are having is in the section of code you posted.  It runs fine for me.  You can try posting a stripped down version of your program that has the same issue.  You might also want to turn up the debugging level in CVI, for this go to Options==>Build Options and make sure everything in the Compiler Warnings and Errors section is checked.  Also under Debugging Options set the Debugging Level to Extended.  This may help track down the problem.

[jr_2005]

The problem is being caused by the declaration of buf[100] being inside the switch() statement. Move it to the top of the function definition and all will be well.

JR

[mvr]

Ok I was able to replicate the problem.  buf needs to be defined before entering the switch statement for the event.  That should fix it.  Interestingly it ran at least one time without a problem.

[mvr]

I see JR found it.  I type so slow.  Anyway nice job.

This fragment works

int CVICALLBACK  RunCallback  (int panel, int control, int event,
  void *callbackData, int eventData1, int eventData2)
{
 switch (event)
 {
 
  
  case EVENT_COMMIT:
   {
   int n = 0;
   char buf[100];
   OpenComConfig (1, "COM1", 9600, 0, 8, 1, 512, 512);  // Open and configure comport
      n =ComRd (1, buf, 100);
   PlotY (panel, MAIN_GRAPH, buf, 100, VAL_CHAR, VAL_THIN_LINE,
       VAL_EMPTY_SQUARE, VAL_SOLID, 1, VAL_RED);
   CloseCom(1);  
   }
   break;
  
  case EVENT_RIGHT_CLICK:
   break;
 }
 return 0;
}

Declaring variables within the local scope of braces {} is something that came from C++.  CVI does support some of these things, and declaring variables like this can be pretty useful.  The problems with the switch statement is kind of ambiguous,  not really sure what the rule would be there, but it is easy to fix. 

Good Luck