What is the difference between "G1" and "G1 "
Particularly in this context
if (memcmp (buf, "G1", 2) == 0)
if (memcmp (buf, "G1 ", 3) == 0) Is this correct for "G1 "?
What is the difference between "G1" and "G1 "
A space at the end...
What is 'correct' all depends on what you are trying to do.
If you are only looking to match the first two characters, then the first one would be correct in both cases - it would match any case where the string begins with the characters 'G' and '1', regardless of what follows them.
OTOH, if you mean to match a whole string, then both of these are incorrect, as they don't take into account the zero delimiter at the end of the string. In C, the endpoint of a string is marked with a null character, '\0', which the string functions need in order to determine the length of the string. When matching a whole string with memcmp()
, you would need to include the space for the string delimiter.
However, I should add that you would normally use strcmp()
or strncmp()
to compare strings, as these are specifically for handling ASCII character strings.
I am working with this code at the moment. It is Arduino based and makes use of the Wire library but you can have a look at the part that I mentioned.
#include <Wire.h>
#define slave 5
#define LED 13
void receiveEvent (int howMany)
{
char buf [10];
byte i = 0;
while (Wire.available () > 0)
{
char c = Wire.receive ();
if (i < sizeof (buf) - 1) // check for overflow
buf [i++] = c;
} // end of while
buf [i] = 0; // terminating null
if (memcmp (buf, "G1", 2) == 0)
digitalWrite (LED, HIGH);
else if (memcmp (buf, "G28", 3) == 0)
digitalWrite (LED, LOW);
} // end of receiveEvent
void setup ()
{
Wire.begin (slave);
Wire.onReceive (receiveEvent);
pinMode (LED, OUTPUT);
} // end of setup
void loop()
{
// nothing in main loop
}
While I cannot say for certain, I would expect that you would be better off using strncmp()
for this, given that you are in fact comparing strings for an exact match. This would also allow you to use the buffer size as the maximum rather than the specific expected size of the string (which as I pointed out earlier, would be one longer than you are allowing for now).
BTW, you may be better off keeping the buffer size as a named constant, rather than having it as a magic number as you do now. That would make it easier to read, and obviate the need to use of the sizeof()
operator.
#define BUFSIZE 15
void receiveEvent (int howMany)
{
char buf [BUFSIZE];
byte i = 0;
while (Wire.available () > 0)
{
char c = Wire.receive ();
if (i < BUFSIZE - 1) // check for overflow
buf [i++] = c;
} // end of while
buf [i] = 0; // terminating null
if (strncmp (buf, "G1", BUFSIZE) == 0)
digitalWrite (LED, HIGH);
else if (strncmp (buf, "G28", BUFSIZE) == 0)
digitalWrite (LED, LOW);
} // end of receiveEvent
This looks much more convenient. But here is the thing. The code that you just edited goes into the Arduino. And this is what I have in Reprap (having atmega644), but it is fine, it is all C++.
I am sending G1 and G28 (which are basically g-codes to run the machine). At first, I put delays but the commands were taking a lot of time for execution.
#include <Wire.h>
#define reprap 6
#define slave 5
void setup ()
{
Wire.begin (reprap);
}
void loop()
{
Wire.beginTransmission (slave);
Wire.send ("G1");
Wire.endTransmission();
delay (1000);
Wire.beginTransmission (slave);
Wire.send ("G28");
Wire.endTransmission();
delay (1000);
}
Now, I have removed the delays but the LED is ON at all times and whenever it receives either G1 or G28, it turns OFF. It does flicker very quickly at the execution of each command, understandably so as there is no delay. But I want it to be ON when it receives G1 and OFF when it receives G28. In short, keep looking and when receive G1, turn the led ON and as long as there is no G28, stay ON. When receive G28, then turn OFF.
Any suggestion as to what I might be doing wrong and how to correct it?
It sounds like your issues are related more to the Arduino interface than to C++ programming. How is the digitalWrite() function supposed to behave? Is it supposed to maintain the state that you specify (LOW or HIGH)? Or is it supposed to trigger a transient switch to that state and then back to whatever it was before? Or if digitalWrite() is a function you have implemented, maybe the problem is there.
Both the codes are there for you to see.
The digitalWrite() function is suppose to behave the way it normally does. The problem is that I want the LED to stay HIGH as long as G1 is executed. And stay LOW as long as G28 is executed. The commands take some time, right !
If I send
G1 X10 Y10
it will take some time to move. I want the LED to stay ON as long as it is moving and after the completion of one command, just keep on looking for what is coming, G1 or G28, and turn HIGH or LOW as defined.
Both the codes are there for you to see.
The digitalWrite() function is suppose to behave the way it normally does.
What does it normally do? I'm not an Arduino developer, that's why I asked. This is a general purpose C++ programming forum, and I don't see any obvious problems in the C++ code you've presented.
The problem is that I want the LED to stay HIGH as long as G1 is executed. And stay LOW as long as G28 is executed.
I understand, but I don't see any indication that the code you're executing would call the wrong function or indicate that the LED should -not- stay HIGH or LOW as you've specified.
The commands take some time, right !
If I send
G1 X10 Y10
it will take some time to move.
Not being an Arduino developer, I don't know what X10 or Y10 should do, or what "movement" is expected from your system.
I want the LED to stay ON as long as it is moving and after the completion of one command, just keep on looking for what is coming, G1 or G28, and turn HIGH or LOW as defined.
Right. And it looks like that's what your code is doing, so I'm at a loss. With any luck, somebody with some similar application-specific experience will notice this thread and contribute some insight.
We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.