Asked
— Edited
Resolved by DJ Sures!
I'm getting an error message in one of my scripts that is giving me some trouble. It's a random error meaning that it will happen every few times the command is run. It's set in a loop so it will repeat. Sometimes it will even cause the connection between the EZB and computer to cut off. Here'e the error:
Error on line 25: Missing String Quotes or Invalid Expression at index 14: "
and
Error on line 25: Missing String Quotes or Invalid Expression at index 15: "
Here's the script to happens in. Seems to center around the print commands. Once I removed the print command at line 25 and the error skipped to the next one. I've also expanded the sleep() commands thinking it was running too fast but it does not help. Thanks for looking :
# This Script will return the actual position number of the left catrrage
# #from the Kangaroo withough the 1,p in the begining.
# #Returning feedback with the 1,p causes problems.
# #Do Not Delete. Other scripts depend on this script!
# -------------------------------------
# Get Roo position
uartWrite(2, 2, "2, Getp", 0x0d)
:waitForData
Sleep(30)
$y_lft = UartAvailable(2, 2)
Sleep(30)
print("Bytes in buffer:" + $y_lft)
if ($y_lft < 6)
# Go back and wait for data again because we did not receive the least number of expected bytes.
goto(waitForData)
endif
Sleep(30)
$Get_Lft_Carrage_P = UARTRead(2, 2, $y_lft)
Sleep(30)
print("Received: " + $Get_Lft_Carrage_P)
Sleep( 50 )
# -------------------------------
# Find out and print if the P is upper or lower case.
# Upper case means motor has finished move ans stoped.
# Lower Case means that motor is still moving.
$P_lft_or_p_lft = GetCharAt($Get_Lft_Carrage_P, 2) #Assign a variable to either a capitol P or Small case p returned by Kangaroo.
Print("P_lft_or_p_lft:" + $P_lft_or_p_lft)
# -----------------------------
# Defeat the P_lft_or_p_lft
if ($P_lft_or_p_lft = "p")
Goto(Lower_p_Split)
ELSEif ($P_lft_or_p_lft = "P")
Goto(Upper_P_Split)
endif
Sleep( 50 )
:Lower_p_Split
$Lft_Carrage_Position = Split($Get_Lft_Carrage_P, "p",1) #1,pXXXX is returned. Get everything after the Lower case p (P is case senceitive).
Sleep(30)
print("Received:" + $Lft_Carrage_Position)
Halt()
:Upper_P_Split
$Lft_Carrage_Position = Split($Get_Lft_Carrage_P, "P",1) #1,pXXXX is returned. Get everything after the Upper case P (P is case senceitive).
Sleep(30)
print("Received:" + $Lft_Carrage_Position)
In addition I noticed that this error also seems to happen when there are over 9 or more bytes in the uart buffer. This call for information usually only returns 8 bytes but sometimes as the loop runs, more bytes then expected are reported in there. My loops keeps running until there are more then 6 bytes found in the buffer. Do you think this could be part of the cause?
Here's what the debug window shows when I get disconnected from the conputer after the above error message:
tired
Your data isn't printable. Stop printing it to the screen or use an array. Look down at your keyboard - only those characters are printable. And if you have a quote to print, it must be escaped.
Unless you are working with ascii data, you'll have to use binary commands.
Now that i'm in front of a PC, to expand on your question...
The code that is generating an error is...
So, that means the UART read is reading a " (quote) or unreadable character outside of the ascii chart.
Did you look at line #25 and see that it is a print() Statement? The print statement can only print characters that are readable by a human, or they must be escaped. if data is stored in a variable that is not human readable, there's no way to print it. The variable manager can inspect it, or printhex will give the ascii value - because you can't print something that you cannot see.
Did you comment out the print() Statement?
Thanks for the reply and suggestions. It's good to know someone cares.
It's odd that you say that my print command shouldn't be able to print anything. It's been showing me position for years now with the occasional error I mentioned. The script would just pass the error by in the loop and redo the request/print. It was not until the latest ez builder update and/or my v2 upgrade that I first started seeing this things stop and disconnect.
Yes I did disabled the first print command and it found a error with the next one so I'm sure you're right. I'll disabled the rest to see if this helps. Thanks again.
I can see that the last update would have affected it because the previous version you were running was many months old - skipping multiple other updates.
That's like updating from Windows XP to Windows 10 and finding that things are different
It's not the print statement that has changed. It's how variable are stored. The original design of EZ-Script was not to support binary operations, because it was a short sighted design. As more power users began connecting 3rd party hardware to the ez-b, there were more binary operations being attempted which resulted in errors. There are numerous threads over the last year on that subject, and a dozen ARC releases with release notes documenting the changes.
The moral of the story is that if you're a power user (Which you are), upgrading more frequently is important. It is only 4 clicks of the mouse to upgrade, the keyboard doesn't ever have to be touched to upgrade. ARC also informs you that a new version is available when loaded.
Thanks for the guidance DJ. Actually it's not that I forgot to upgrade ARC, it's that I was busy completing my robot build between the time periods you mentioned. The scripts I'm using now were written back then and seemed to work nicely. Now that I have the robot mostly ready to accept more complex moment scripts is when I'm actually "power" using ARC again. Thank goodness!
So, back to my issue; I actually went back and commented out all the print commands. Sadly however this same error message is now happening on different command in the problem script. Here's that command now:
Sounds like I may need to find a different way to write this script? I really don't know what changes I need to make to get this script to work. I'm wanting this script to send a Simple Serial command request through the Uart to the Kangaroo for position info, read that info when returned then assign a variable to it. The issues I was having before was that the returned position info looked like this:
A upper case P would mean the movement was complete followed by the position. A lower case p would mean the moment was still going on followed by the current position.
Personally I really only need to know when the movement is complete. If there is a way to write a script that will look for a change from a lower case p to an upper case P that would work also. The above script that I wrote a while back could be modified to do this but I'm now not sure it is a workable script. Do you think this will work or is there a better way to write this? confused
I assume the issue is with a new line completion.
What would probably benefit you is an actual plugin for this piece of hardware.
Where can i get one? Do i need the kangaroo or do i need additional components? I'll order one and create a plugin for you. That way you will no longer need complicated scripts to send/receive commands to this device.
It will operate similar to the ssc-32 and dynamixel by using virtual ports.
Really nothing to contribute to this thread except DJ really kicks axx. I don't personally use a kangaroo but it seems he's on a plug in making/fixing rampage!
Oh My! Either your a really cool helpful, thoughtful CEO or your just getting tired of my whining.
Either way, you rock DJ.
The Kangaroo x2 operates as a daughter board for the Sabertooth. Any of the Sabertooth models will operate with the Kangaroo except the Sabertooth 2X5 (It will work also but you need to change some settings inside the 2X5 first). The Roo gives any of the Sabertooth's speed and position control.
Also for the roo to run and do it's Autotune it must be attached to a motor and have a feedback device like an encoder. All parts of the circuit must be in place and working properly before the Roo will complete a successful autotune. Once completed the Sabertooth/Roo combo useually runs really smooth and is very solid.
I'll gladly buy the parts you need and have them sent to your workshop. I actually have a new Kangaroo and a Sabertooth 2x12 here that I can get in the mail to you as soon as tomorrow. Just let me know where to mail them to.
Thanks again!
Okay, mail it and that'll work good. I have the USB driver for will to complete testing and then I'll do your plugin.
Outstanding!
Will! That guy? I'm sure he wouldn't mind stepping aside and letting you do mine first.... LOL. Just kidding. Will's project is an important one and I'm sure he'll be needing your plugin asap. I'll gladly wait.
Do I mail it to this address?:
EZ-Robot Inc. #10 6120 11 Street SE Calgary, Alberta T2H 2L7
If not please send me your shipping address.
Many thanks!
Yup, that's the correct address!
Thanks again DJ, I'll get the package with a Sabertooth 2x12 and a Kangaroo X2 out on FedEx later today or tomorrow. I know your working on Will's project so there doesn't seem to be a huge rush to get this to you. Either way it should arrive next week. I'll mark it to your attention.
In the meantime I'm going to keep working on this issue to see if I can learn something. Afterall, that's what life is all about isn't it?
I think I made a little progress last night. I think I found a couple underlying issues that may have been causing the EZB to disconnect. After making a few script timing adjustments I was able to run the arms several times without disconnecting the EZB. I still need to clean things up in the scripts a little and do some more testing to make sure. I think what was happening was I was sending commands through the same Uart port to both channels of the Kangaroo to fast or at the same time. I have one Kangaroo X2/Sabertooth controlling both arms through the one Uart port of the EZB. The one Roo/Sabertooth combo can control both of the DC Elbow motors, one in each arm. The combo has two channels, one for each of the two motors. I've found in the past that almost 100% of any issue with my EZB disconnecting or locking up happens when I screw up a command involving a Uart port. Mostly this happens if I try to send a command through it that is not correct or if that Uart port hasn't been initialized yet.
I'm still getting the error in my OP and it still seems to be random. However now it's not disconnecting the EZB and I don't think it was the cause in the first place. This script now just loops and seems to moves past the error until it gets a good read. Again, I'm not sure and I'll need to do a little more testing.
I think what @DJ is saying when he's talking about a binary operation and the variables storing info differently than before is that the characters I'm trying to store in the variables can't be understood? In this case will it work better if I just start using the characters that the script commands are looking for instead of using variables to keep the errors from happening? Am I totally off here? I know the characters that will work are the ones located on a keyboard. With that in mind the returned position of the motor in the Uart buffer from the Kangaroo looks like this when the move is still in progress:
The changing "P" really complicates my effort to write a script. If I have a simple script looking for a lower case p and it changes to the upper case P the script will fail or just keep looping. tired What fun!
So the process of learning how to use this wonderful technology keeps going. What a cool journey.
I'm always open to guidance. Feel free to educate me or point me to resources that will help. 
I think there was a typo or confusion there Dave. Not sure what DJ was saying about USB drive but "will" was not "Will"
USB connection for Will (fxrtst)
Understood Will. Well Will, will you mind if I assert my will here in all things Will? I insist that Will's project be given full priority if DJ is willing. I'd hate Will to willfully insist that he was first in line. Will , I hear you're a scary and dangerous dude when you're mad and I don't yet have my Will prepared. God willing, it won't have to come to that. (That was a whole lot of Wills)
Ahh yes that was me! Brain fart....can you hear that sound ? That's brain cells dying! Thanks DJ!
Lol Dave!
After working on this issue for the past few days and trying many different things I'm certain the EZB disconnect issue was that I was calling for information from the same Uart port at the same time by two different scripts. After I reset the timing of these commands the disconnect problem went away.
However no matter what I do I cant get the "random" Missing String Quotes or invalided expression" error to go away.
I rewrote my script to determine if the "P" in 1,p820 is upper or lower case. This tells me simply if my move has completed or is still in process. After disabling all the print commands that we thought were the problem I'm now getting this error in other commands. Here's that script:
This is the latest problem command in the above script getting the Missing String Quotes or Invaded Expression error (and it does not have any quotes in it):
It has got to be as DJ says and be the Variables causing an "Invalided Expression". In the above command I'm trying to extract the 3rd character of something that looks this read: 1,p820. I'm trying to pull the "p" out and store it in a variable. I'm basing this on the example in the Scripting Cheat Sheet:
Maybe I'm using the wrong command? should I be using the GetByteAt command? Is 1,p820 outside of readable ASCII?
Any thoughts? confused
It's the wrong UARTRead command. Use UARTReadBinary() and read the data into an array. You split the data into an array anyway.
Here...
OMG thanks! eek You saved me about two days of struggle and probability saved my marriage in the process. LOL.
Looking through your rewrite I was very close. Just missing a few of the right words and proper brackets. LOL. I'll give it a try.
OK, that seems to be running when I test it in the console and ARC is connected to EZB in the robot.
However, I'm getting the number 80 returned instead of the "P" I'm expecting. Do I need to convert this returned number to a letter "P" somehow in the script after it's returned? If so will this number be different if a lower case "p" or some other numberis returned? If the number 80 is equivalent to a "P" and I know it then this will work.
Sorry, I feel like a blind man here. What do the [] do at the end of: $Lft_P_or_p = $Get_Lft_Carrage_P[2] ?
Here is what is returned in the console:
80 is upper case P. 112 is lower case p. See: http://www.asciitable.com/mobile/
Alan
Ah ha! Alen your the best!
Believe it or not I was just coming back to this thread to say I just taken a look at an ASCII table and just found this info out. I'm like a blind pig. Once in awhile I can find a nut. LOL
Even so, Thanks for this info as it confirms my blind find. Tomorrow I'll modify my script to take the return of these numbers and make it do what needs to be done.
Thanks again!
Yes! Problem solved! Changing the UartRead Did the trick! Then knowing I will see the returned value as the number in the Acsii table that corresponds to either a uppercase P (80) for a completed move or a lower case p (112) for a move still in progress was the final answer. No more errors at all and everything is running smooth and safe.
@DJ, I'll still send you the Kangaroo X2 board and the Sabertooth 2X12 if you want them. I have them packed up with the custom papers attached, a FedEx shipment completed and their ready for me to drop off. However as of now I think I'm over the hump with any coding issues using these boards with ARC. If you still would find value in having these control boards and writing a plugin for others I'd be thrilled to still ship them to you. Please let me know and they are yours!
Thanks once more. I'll sleep good tonight.
Please use this thread for your issue and do not create a duplicate.
Use the binary uart operation for communicating to your device as demonstrated.
What else do you need to know?
OK. No problem. Sorry you had to go through the trouble of deleting my post. I thought the question was different from me asking about the String Quote error.
I'm now trying to get a read of all characters past the P in this: 1,p-8 or 1,p1600000. I've tried using several of the getbyte operations with the script you corrected above but can't seem to get it right. Any help would be appreciated.
Okay - i'll repeat what is happening, again. The kangaroo thingy is returning a byte (or more) that is corrupting the string.
This is an ascii chart
The readable characters in the alphabet and numerical, etc that you can visually see with your eye balls are between 32 and 126. Everything else are values that have no readable representation because they're commands. You cannot display an ESC or a BEL because they do not exist in our alphabet. There are no words in any language spelt with the ESC (ascii 27) character, because they do not exist outside of the realm of a computer.
You cannot store these unreadable values in a string. A string is a sentence, like you are reading right now.
READUART(), as per the manual, reads readable ASCII. This means if you are reading data that is not ASCII then the Binary Uart Read would have to be used.
However, i'm tempted to add a filter on the ReadUart() command that removes binary characters. Doing so will be cheating for any educational value that people get from using ez-robot.
Your solutions are...
While you wait, this might be a good opportunity for you to explain what you working to accomplish with Reading from the UART so i can better understand the objective.
@DJ
How about instead have a "verbose" error message displayed so the user will understand that their "ascii string is unreadable due to non view able ascii characters"? I get some errors still from data returned from the roomba... I am now thinking that some of this data isn't readable ascii data (binary) so it's not working properly with UARTRead...The Roomba is not readable ascii and is the exact reason why binary operations exist.
Logic either works or doesn't work. There is no in-between.
I cannot display errors and continue processing because the data is not valid. Binary operations and functions are not something i magically invented, there is no reason to fear them. Binary operations merely return an array of bytes.
It's not that i have a choice of what can be stored within a string. That's like saying you have a choice of whether or your you can use your automobile as a dishwasher. The inherit design of a STRING is exactly what I previously explained - readable characters for humans.
A string is a string because it is a string.
I do have an "idea" that can escape some more characters for the UART READ but it will most likely introduce Dave into another struggle.
The Binary Read operations were created for just this though.
@DJ... ah but some UARTRead's work ok on the roomba... for example I can read the roomba's bump, IR sensors and battery voltage using UARTRead. However other sensors like reading the milliamp capacity of the battery fail using UARTRead.... So my logic was maybe some read returns are binary and some use ascii? However I do understand what you are saying here....
I should also add that using the binary uart commands for roomba will be even easier than attempting to use the ascii uart. This is because your command is stored in an array of bytes. Each index of the array is a different byte. For example, if a packet command was to be 4 bytes, it would simply be something like...
It's not that some return binary and others return ascii - it's that some values just happen to be within an ascii range.
The bump sensors for example actually use the BITs of a byte. Each BIT represents a sensor value. So all bits off is a 0x00, which is a null character that terminates a string.
@DJ.... Ok that makes sense... It's strange because bump returns are a single byte while voltage and milliamp capacity are 2 byte return (high and low byte). So what's strange is that Voltage returns ok, but milliamp reads fail... They should be basically identical in what type of data they return, though... Weird
It's most likely that the milliamp read is generally a larger number - or who knows.
David, i made an escape "hack" on the UART, i2c and com reads in this update for you: https://synthiam.com/Community/Questions/9933
Because the device is returning strange data, it "may" be visible in the ReadUart() string and introduce parsing struggles. Try it
Many thanks for taking the time to work on this with me. I'm not adverse to struggle and am enjoying this learning experance. Until I found EZ Robot 5 yrs ago I had never written a script and had no idea on how to get a servo to move or even a DC motor to move in reverse.
@DJ, telling me how binary vrs ASCii works helps me to understand a little better what is happening. I really didn't know that the binary reads are cut up into an array and the reaon sometime the ASCii Uart commands work is because they share some of the same readable characters.
What I'm trying to do with this script is to simply read a position of a carrage running on a rail as it moves and also when it finishes it's move. I have a Kangaroo X2 commanding position control and getting feedback info from an encoder attached to a motor shaft. I have this script looping, reading the position and trun it into a variable. There is a second script watching that variable and when the variable reports that the carrage has reached a certain position a second motor is safe to move and the first looping script will halt.
In real life, one motor (the one being commanded by the Kangaroo with feedback from the encoder) is moving my B9 arm out of the body of the robot on a carrage attached to a rail. Once the arm is compleatly out of the robot only then is it safe for the arm servos and DC motor to start moving it around. I need to know from the Kangaroo what position the rail systmem is in and the carrage is clear of the robot's body so it's safe to move the arm.
The Kangaroo will return the position in the following way:
Thanks to your help so far I'm able to understand that I need to use binary commands and am able to get one character. I was getting the "P" to find out if the move has been completed or is still underway. I'd really like to find a way to find out the actual position read. These are the string of numbers after the "P". in my system they could anything from -8 to 160000.
I hope that's understadable. Thanks again for the assist. I'll get that Sabertooth and Kangaroo shipedout to you in a day or so.
Did you try the release mentioned in my previous post?
Oh ,sorry I didn't mention that. Thanks also for doing this extra work. I'll give it a try tonight after work. I assume it should be used with the ASCII Uart commands?
Correct - with your previous script
I upgraded ARC with your new version. I can't tell for sure if the changes you made worked.
When I first ran the script I had trouble getting the thing to loop when called from another script and I would still get the error first mentioned if the script ran to fast. Then I changed the timing of the loop and limited how many times it ran. After a few tries I was able to get it to loop without an error. In the script there are several calls on the uart port. I'm wondering if reading the Uart port to fast or calling the looping script before it has completed running is causing the error?
You can't read the uart from multiple threads (i.e. different scripts) at the same time. Think about it... It's called SERIAL for a reason
Actually I was reading the variable with one thread that was changing in the looping script. That should work, shouldn't it?
Not if the variable is changed during the other script thread.
Can you not do everything in one script?
This is interesting. So, if I have a script looping and applying a different value to the same variable each time it loops, when will the value actually change globally so other scripts can see the changes? I'm also asking how long it take to have a variable value change globally once it's stated?
I can have most everything done in one script. At least the one process of moving the carriage out of the robot body and reading it's position. However once the carriage is safely out of the torso the arm animation will have to be handled by the Auto Position control. It needs to know the arm is out of the robot as soon as possible so the animation can start quickly.
Yes, other scripts will see the variable change. What DJ was saying is you can't have two scripts reading the UART. But one can read it and populatr variables, and others can act when that variable changes.
Alan
OK, Everything seems to be running smoothly now. I've combined the scripts and it's running without errors. Again, I'm not sure what really did the trick, DJ's filter, working out the timing so the Uart was not being called by different scripts at the same time or combining everything in one script. Most likely, it was all of the above. Many thanks again for helping me work through this.
Here's a video of the final result:
Love seeing it all come together.
Alan
Great job!
Bet that feels great! You did it!
Great to see him come alive, even if it's so you kill him.... LOL
Your dream has come true !
Have fun,
Ron
Yes, It's great to see it working and it does feel great!. However, I fully understand I didn't do it alone. Thanks for the guiding hand and assist!
@Andy, you're correct. My dream is coming true. I'm surprised you remember me saying that. Thanks.
@DJ, Next Wednesday FedEx should deliver to your office the Sabertooth/Kangaroo I shipped to you. Hopefully it won't get caught up in customs. I'm sure a plugin that will make it simple to send commands and receive feedback from the Kangaroo will be a huge help and make using this cool little pair of control boards much easier to use with ARC. Thanks for considering doing this.
Got your kangaroo!
Excellent. I was hoping there wouldn't be any issues getting through customs. The paperwork sucks and I wasn't sure if I had everything right. Thanks again for offering to do this. It's not a priority for me right now that you helped me get my script worked out. Feel free not to put it on top of your pile. However I'm looking forward to seeing what you come up with.