Help testing RoboEmu 1.10

OK, I just finished RoboEmu 1.10, but need some help. Based on the insane number of bug reports I got for 1.09 and 1.09b, I was hoping to get a few individuals here on ChiefDelphi to help me test it out before making an “official” release.

New in this version:
A lot

Fixes in this version:
even more

Basically, I implemented everything in the PBASIC 2.5 spec with the exception of conditional-compilation and the PIN command. I also made a few changes to the variables system.

If you are interested in helping, I would appreciate it very much. As I said, I don’t want to update the links on my website or in the whitepapers until I have some confirmation that most of the bugs have been worked out. Therefore, I’ve attached the new version to this post. The source code is a little on the large side, but if you want it I can email it to you.

Thanks in advance to any and all that are willing to help!

–Rob

[edit]
I fixed the EXIT error. File now attached to new post (look a few entries down).
[/edit]

it wont work with default edubot code. it gives me an error on line 405 about an exit outside of a for loop

*Originally posted by redbeard0531 *
**it wont work with default edubot code. it gives me an error on line 405 about an exit outside of a for loop **

And it doesn’t make any difference whether you click on Yes or No in response to the question “Do you wish to quit?”… The program always exits.

Also…for future consideration…

Some sort of control to simulate the digital inputs would be nice (maybe you have them and I am just as dumb as I look).

*Originally posted by Caleb Fulton *
**Also…for future consideration…

Some sort of control to simulate the digital inputs would be nice (maybe you have them and I am just as dumb as I look). **

Are you talking about digital inputs other than the 16 switches that are on the right side of the Inputs dialog? If so, please explain as I’m not familiar with any other inputs.

As for the EduBot code: thanks for the info. It’s another one of those annoying errors where it misinterprets any line that starts with the word EXIT as being an EXIT command. The fix should take approx. 30 seconds. Oh well…

The quitting thing: thanks, gwross! That’s one of those things that I haven’t touched since version 1.05 and just assume still works. I’ll revist it now that you’ve mentioned it. Now that I think about it, it’s probably been that way since I converted to MFC way back when.

Any comments on PBASIC 2.5 support? As far as my testing could determine, everything in the 2.5 spec now works except for PIN and conditional-compilation. Anybody care to back this up/find a flaw?

Thanks again, and keep 'em comming!

–Rob

*Originally posted by rbayer *
Any comments on PBASIC 2.5 support? As far as my testing could determine, everything in the 2.5 spec now works except for PIN and conditional-compilation. Anybody care to back this up/find a flaw?

Yesterday, it worked fine for our team using 2.5 code.

I fixed the exit error. The new version is attached to this post. If people are still willing to look for bugs, etc, I’d greatly appreciate it.

–Rob

[edit]attachment removed as requested by Rob. See release in white papers.[/edit]

OOPS…

DUH on me :frowning:

Worken great so far…

Feature request: It would be nice to have the ability to reverse PWMs. This would be very useful in drive train programming as the left and right sides are negative to each other. I could then see when it is turning and what not.

I wish I had used this the past 2 years. Took me a few trys to figure out how to use it but once I did (which really wasn’t that hard) it helped tremendously. I found some errors in my code that would have taken me much longer to locate, especially since I have to email it to someone still at the high school who would then use it eventually and email me back if it didnt work. I’ll defenitly be using this alot more.

*Originally posted by redbeard0531 *
**Worken great so far…

Feature request: It would be nice to have the ability to reverse PWMs. This would be very useful in drive train programming as the left and right sides are negative to each other. I could then see when it is turning and what not. **

I’ll think about it. It’s a good idea, I’d just be worried that somebody would think their code was actually reversing the PWMs and get all confused when they loaded it in an actual robot. I do agree, however, that it would be nice as I have to think hard while running my code through it to see which way is left and which is right.

Anybody else have anything that doesn’t work or that they’d like to see added? I’ve got nothing but time tomorrow and need some projects…

*Originally posted by rbayer *
**Anybody else have anything that doesn’t work or that they’d like to see added? I’ve got nothing but time tomorrow and need some projects… **

I hope you received the message I sent last night (early this morning :o ) I think there’s lots of meat there for you to chew on tomorrow.

If you haven’t received it, it may be because the attachments made the message too large. Let me know if I need to split it and resend.

I have a question on how to use Roboemu. First i open the file with my code in it and I can emulate it, it works just like it should, etc. The only problem is when I go back and change my code in the Stamp Editor. I save it there, but is there anyway to get roboemu to reload the code without having to get out out of roboemu, get back in and reselect the file to emulate?

It works great, that program saves me TONS of time. I don’t have to wait until Thursday nights to test my code anymore.

*Originally posted by Morgoth *
I have a question on how to use Roboemu. First i open the file with my code in it and I can emulate it, it works just like it should, etc. The only problem is when I go back and change my code in the Stamp Editor. I save it there, but is there anyway to get roboemu to reload the code without having to get out out of roboemu, get back in and reselect the file to emulate?

You don’t have to get out of RoboEmu to reload your file. Just go to Open Files, and reselect your file. Or if you have saved your project, you can go to Recent Projects, and reload it there (probably the easiest method.)

BTW, one of the things I already suggested to Rob offline was for RoboEmu to check the freshness of the file on disk before beginning emulation.

I should have thought of that. Thanks. It would be nice to have your idea be an option, for those who want it and those who don’t.

For now, I think I’m going to do a release as-is, just so people can start playing with the 2.5 syntax. After I finish packaging it and updating my website, I’ll sit down and try to implement as many of these features as I reasonably can. Some of them I know will be easy, but some I’m going to have to do some pretty heavy reading out of the MSDN library to get to work. 1.10 final coming later today. 1.11 coming later this week.

will the other syntax still work, becuase my team is using the old syntax.

'--------------------------not directly related-------------------------------
Well, I’ve got an idea that would take about 2 years to complete. Obviously impossible, but I figured I’d through it out there anyway. I was just thinking - we’re given cad softwware, and pbasic, and we can get roboemu/anything else you make, so…

Use pictures created in the cad program (or create your own) - allow ways to define joints, and where motors are. Example, I draw a 3d arm with one joint, and then select the motor you drew and define it as pwm1. Then, when you emulate, it runs all the motors, etc. and your robot moves around a field. You could (in the technically possible sense) even integrate sensors - define this line as retroreflective, allow inserting extra objects, etc.

Like I said, not a prayer it’ll ever get done, but I thought I’d throw it out there.
'-------------------------end not directly related---------------------------
As for RoboEmu 1.10…Go over your code that checks for too much time between serout command, we have code that serouts frequently (no questions often enough), and serins what should be often enough. We run it, and it goes through the loop many times, quickly, and gradually slows down, eventually stopping with the ‘your robot is dead’ message.

Maybe you could just put something to turn the serout error on and off, via a menu or some thing. Also, if you run the same code on a faster computer, it does not slow down, but can run forever with out an error. If you move one of the pwm’s, even for a very short time (50ms), it will give an the error. What timing does the RC need to not have a basic run error?

As of right now, it’s setup to allow up to 1sec of delay. That’s FAR more than the RC will ever tolerate, but I figure that it’s a good indicator of infinite loops, etc.

Anways, grab the official version from my website or the whitepapers as it changes the timing from 400ms to 1s.

–Rob