Yes but for some reason it is not receiving it in the Arduino as the debug led never turned on when I had it under cmd==0. Wonder why it is not accepting it.

1. Is the Arduino connected to the PC via USB?

2. are there multiple arduinos chained together?

3. are you sending the SetAsHome command while it is calibrating? You cannot send a command while another command is executing. The arduino does not have a significant input buffer on the RX for UART. That means it might get lost if it's doing something and you send a command.

In the Arduino, the data arriving in the UART from USB sits in a small buffer until it is read by the code (Serial.ReadByte). I'm not sure about the size of the input buffer on an Arduino, but I know it's tiny. In fact, it might only be 1 or 2 bytes. So there's a chance the SetAtHome command is lost if you send it while it's doing something else, such as calibrating.

Yes the Arduino is connected to the PC via USB. For testing purposes have only 2 connected- a master and a slave. They work as expected going to positions. No I am not sending SetAsHome while calibrating. I am going to a position 10000 ariving then SetAsHome it mentions Done then checking it by putting position 1 and it moves 10000 steps which means int never Homed. I then ping both V1 and V8 individually and it returns 20230223 which is fine. I then put in position 10000, send script to calibrate, it mentions Done, then I send position 1 and it moves 10000 steps which means it never calibarated.  If I ping it and it works doesn't that mean the cmd variable is not overloaded or lost?

Quote:

Thanks for the responses. I'm using the Nano Every USB for programming and Serial1 for communicating with a motor driver. The software serial is used to write to a data logger. I'm not having a problem sending bytes to the motor driver, that works and it responds fine, but I am having trouble getting bytes back from the motor driver, so I was just wondering what the buffer size was as I explore different options for capturing the driver return bytes. The same procedure works fine on the Mega, but there I use Serial.event, which I'm told doesn't work on the Nano Every. Changing the core, or whatever, is far beyond by understanding or ability. So, at this point, I'm just curious as to what the Serial1, and software serial buffer sizes are.

Thanks, John-

Quote:

Please post your code and a link to the motor driver/data sheet. There should be no difference between using Serial.event and if(Serial.available()). If you can capture the driver return events with a second hardware serial port on a Mega, you should be able to do so on a Nano Every with Serial1. The default Rx buffer is the same 64 bytes on both. It would be unusual to overflow a 64 byte buffer before you can read it, but if indeed that is happening, you can increase to 128 or 256. Why do you think your communication issues are caused by buffer size and possible overflow?

From your description and the size of the buffer that Dave provided, I don't think it's exceeding the buffer. So, my last thought is void.

I can't understand how the CMD == 0 condition isn't being hit. I will have to load our setup later today and see if there's any way I can reproduce this - maybe it'll give me thoughts on how it can happen to you.

Yes it's very strange, have been poking around the code for possibilities. How can I buy your drinks tonight? It's all appreciated. Here are a few things that I saw which are probably off base but it may trigger a side thought. In the photo -if stepper current pos = the target position then void calibrate.Well current position already is where I told it to go (target position). In another area it states stepper1.setcurrentposition(0)  but you already said that was off base but it looks like you are setting it to 0.  Another possible clue is that it states that it is Done very quickly .02 seconds which means the code went somewhere and completed but did not give me proper results. Maybe something in here will help.

Oh geez, this is so simple. I just wasted 4 hours on this because I didn't notice your command vs the manual haha...

Here's the manual...

Quote:

ControlCommand("Stepper Servo", "Calibrate", "ID"); This ControlCommand() takes the virtual servo port as the ID parameter. It will instruct the Arduino with the ARC Stepper servo firmware to move the stepper until the End Limit Switch is triggered. This command requires an end-limit switch; otherwise, the stepper will rotate indefinitely. Refer to the Limit Switch section in this manual to read more about a limit switch and how to configure it.

ControlCommand("Stepper Servo", "SetAsHome", "ID"); The SetAsHome command will set the current position of the stepper as servo position 1. For example, if you move the servo into a position (i.e., 90) and then specify the SetAsHome control command, the current position will become the new servo position 1 for that virtual port. servo position 1 is as low as a servo can move, so when you send SetAsHome to the specified virtual port, it will now refer to the current position as 1.

The manual states the "ID," not the servo port. So you would pass an 8, not a V8. That being said, I think it makes more sense to use the servo port than the ID.

We have been using the ID in our tests because that's what the manual states. We didn't notice you have been using the servo port.

The robot skill should be changed to use the servo port to avoid future confusion. Until it is changed, use this...

ControlCommand("Stepper Servo", "SetAsHome", 8);

Version 21 of the robot skill has been updated to accept the virtual servo port and NOT the id: synthiam.com/Support/Skills/Servo/Stepper-Servo?id=21134