SERIN
arnold113
Posts: 43
I've got a position control module sold by Dimension Engineering that I'm having trouble getting data into my BS2 from. I give it a command of SEROUT 14, 84, ["1,getp", CR] ( requesting the position of #1 axis) The control module answers with the position. A 1 followed by a , followed by a p (for position) followed by the position data xxxx then an enter key. My problem is trying to extract the position data. When I try SERIN 13, 84, [DEC BAND_POS] the BS2 inputs a 1 (#1 axis number). I tried SERIN 13, 84, [WAIT ("p"), DEC BAND_POS] but the program just waits and waits and waits. I've tried every combo of the WAIT command I can think of but it still locks up waiting. My program is very dependent on knowing the position of #1 and #2 axis. Any help you can give will be appreciated.
Thanks, Arnold
Thanks, Arnold
Comments
If the expected incoming data is 1,p####<CR> always, try:
This might work, but maybe not if the data is very fast.
In that case, try this:
which will read in up to 8 bytes into array or stop at a <CR>. Then DEBUG the array, one character at a time to confirm what you expect:
if that works, then you will have to convert the digits in the array to your number:
This assumes that valid data is in the array. You should probably check it first, array(0) = "1" array(1) = "," and array(2) = "p" to make sure.
Once the SERIN command is done, you can re-use the array() bytes for other things until the next time you use the SERIN command again.
char VAR BYTE
SERIN 13,84,[char,DEC4 BAND_POS]
Processing a single ascii character is faster than processing a DECimal value. The Stamp will ignore the leading p in the ensuing p#### .
Many devices have only one stop bit between bytes and that does not give enough time for the Stamp to complete any fancy processing. Can you select two stop bits for the device?
I agree totally with Sapphire about the STRing method. After the initial setup time, it is by far the fastest way for the BS2 to capture serial input.
Thanks, Arnold
There are faster BS2 stamps, namely the BS2sx and BS2p which will work at 9600 baud using WAIT and both have 8x as much program space. The BS2p also let you read data from SERIN into scratch pad memory, which you can then decode without using the array() technique. And there is a BS2px which is the fastest, but there's no way you need that for 9600 baud.
Post your code if you need more help.
Thanks for your help, Arnold
When given a get position command the kangaroo responds with 1 or 2 (axis number) followed by a comma then a P or a p (P for axis in position and p for axis moving) followed by a four or five digit number for position (depending on which axis) then all this is followed by return newline (CR). Com is 9600 baud, 8N1 but can be increased in baud rate but cannot be decreased in baud rate because the kangaroo can’t distinguish between serial and servo signals at 2400 baud.
uOLED-128 has exactly this problem with BS-2. I was able to just ignore the responses, but that is obviously not a solution here.
Not necessarily. If the BS2 is missing the initial bytes it may be catching one from after the "p". If you do like Sapphire mentioned and dump the entire string into an array you should be able to see all characters received, regardless of what they are. To prevent the "lock-up" you could also put a time-out on the SERIN and then display what you did get. In doing so I would preload the array with null values so you know what values are from the most recent try. Actually if you pre-load the array with CRs you shuld be able to DEBUG the array as text with one statement.
I agree that the fact that the "1" or "2" was received with the DEC modifier does give hope to receive the full response using the STR modifier. The big unknown is as Chris pointed out time it takes between issuing the command and the point at which the Stamp has interpreted the SERIN command and is actually ready to receive the data. It takes the Stamp a little less than a millisecond to do that and to be ready. If the Kangaroo starts to send back the response with only 100 microseconds of delay, the Stamp will get off on the wrong foot and won't receive any of the data correctly. Once the Stamp is ready, the STR method is by far the fastest. Any other modifiers or things like flow control or timeouts will lengthen the time it takes the Stamp to interpret the command and to be ready.
Definitely if you can, the BS2p is the way to go. It is substantially faster and has more memory. Also, it has the SPSTR command, which directs the serial input quickly with timeout to the scratchpad RAM, to be retrieved using the GET command. You asked about the limited amount of RAM memory. The BS2p too has only 26 bytes of regular RAM, but it also has 128 bytes of scratchpad RAM. That is great for values that change less often, PUT and GET. There is also 32kbytes of EEPROM organized into 8 slots of 2kbytes each, where you can store program modules and/or data.
Thanks for everyone's help, Arnold
Arnold
No problem. You have inspired me to do a test though to find the response time of the BS2 on the SERIN. I was thinking I would create a quick test that used a Propeller to receive a command from the BS2 and respond each time narrowing the response window until the BS2 misses the response. This would give me some ideas on the minimum response time. I would probably try the test with a few various formatters to see how things vary.
https://www.parallax.com/product/28030
I'd gladly post for free one of the USB cables that I got with my 8 Radio Shack Quick Starts.
They are multiplying!
I wanted to let you know that I did some empirical testing to try and determine what the minimal response time would be for a BS2 SERIN command following the SEROUT command. So what I did was wrote a program to simulate the BS2 sending a command to a controller and getting a response back from it. The controller is just a Propeller chip programmed to respond to the command and return a response. I used your position command as an inspirational guideline. Hopefully this information will help others. I am planning on doing more testing with various formatters and other options, but for now this is how it works.
The BS2 sends out the following command:
The channel is actually cycling each time through the loop from 0 through 3. The Propeller is waiting for the "!POS" and then grabs the next character as the channel and then the CR. It then waits a predetermined amount of time and then responds with the following information, "p<channel><delay low byte><delay high byte><checksum>" where the channel is a single byte from 0-3, the delay is the number of microseconds (sent as low byte then high byte) and the checksum is a single byte additive checksum.
The BASIC Stamp 2 then receives this data and if it is good it sends an ACK to the Propeller chip. If not it sends a NAK to the Propeller chip. When the Propeller chip gets an ACK it subtracts 1 from the delay value and then waits for the next command. If it gets a NAK it adds one. In this manner we determine at what point the BS2 becomes unresponsive to the response from the Propeller.
In my testing I found that the delay that caused a NAK was at 380 microseconds, while the previous value which generated an ACK was at 425 microseconds. Granted there is a small gap in there that I still need to hone in on, but for now it is safe to say that the BS2 requires about 425 microseconds to prepare for a SERIN of the 5 bytes I am receiving in the above example. 380 is too short a time. And I know I have seen devices that respond in the <100 microsecond time range causing the BS2 to miss their response.
For example a customer contacted us stating that his Emic 2 TTS was hanging up and not responding to the volume command. It turns out that the code is designed such that when a command is issued the BS2 waits for the prompt ":" before executing any more commands. When you're sending speech it takes time to say things and therefore the BS2 will happily wait for the prompt and issue the next command. However when you send a volume command the Emic 2 TTS responds in approximately 300 microseconds, which as we saw above is too fast for the BS2 to respond.
This stuff is easy to see on a scope or logic analyzer if you have one. Not so much without. Parallax carries the Saleae Logic 4 to help find such issues. I hope this helps.
https://www.parallax.com/product/32307
Attached is an screen capture of the Saleae Logic Analyzer being used to determine the response time of the Emic 2 TTS.
Edit: Strike that. The image won't attach.
Thanks, Arnold
Thanks. Once the Propeller gets the command it is supposed to wait a set delay and then transmit the response. Each time it gets an ACK it reduces the delay. However, while the delay seems to be functioning properly, my Logic Analyzer is saying the delay each time is all over the place. I can only guess it is related to the FullDuplexSerial4Port object in some way, like FIFO buffers or something. I am thinking of switching to another method since I am only using 9600 bps.