Grbl Simulator #112
Grbl Simulator #112
Conversation
|
Well you've been busy. :) There's a lot of changes to breakdown and analyze, but I do like the idea of moving the runtime commands into a new module. I'd like to really look into everything before we integrate it in. One comment though, you've changed all of the double's to float's. As far as I understand, the AVR compiler automatically changes these to float upon compilation. But, as far as portability to more capable processors, I think it might be a good idea to keep the more critical computations that need more precision as doubles, but we may have to figure out what variable need these more accurate values first, like the arc computations. (that is if you haven't done this already) :) |
|
Yeah, sure take your time. With so many changes I'm almost sure you will find something :) BTW: As for the GUI grbl feeder, have you seen https://github.com/winder/Universal-G-Code-Sender? It works like a charm. But apperently there is an issue with rxtx on Macs where you have to create a special directory /var/something... its written on the Universal-G-Code-Sender site |
|
So I gave it a go on my Mac, and I had to do a couple of things to get it working. In the Makefile, changed the compiler to 'COMPILER=gcc.exe' and the removed the '--gc-sections' compiler flag from the build statement. (For some reason, my Mac didn't recognize this.) I ran the executable and got the Grbl prompt. It seems to work well, but the only issue seems to be that it does not respond to any run-time commands. So, I've been contemplating why this would be useful, given that this adds another (major) thing to maintain and that all you need to do is connect your Arduino to your USB port to see how Grbl responds. But now I see where you're going with this, creating a previewer for interfaces could definitely be a handy tool. I also like how it uses all of Grbl's actual code and wraps it into an emulator. I guess my alarmist side wants to ensure that the emulator truly outputs exactly the same output as an Arduino would. If not, then a user could simulate their code to verify it all works, and then find that their parts are screwed up after a physical run on their setup. For me, I think this would be great if we can get data from the stepper pulses from this emulator to be able to process and view it without an oscilloscope (which is limited in a few ways). Or track how much processor usage there is... Then again, why wouldn't a hardware emulator be just as effective? After doing a quick search, there seems to be a couple out there, but I haven't seen what they can do. |
|
Ah, now I think I know what you mean with "more capable processors": other micro-controllers? Just noticed, that my pullrequest cannot be automatically merged, although I tried to work off your latest commit. I could rebase it if that helps. |
|
Yes, I've looked into the avr emulators myself a bit and figured that they are way to slow (much below realtime) and cumbersome to setup and operate, especially with serial communication. |
|
Interesting. Maybe emulators will get better in time, but what you have here would definitely work for the ideas you state. Plus, I have to say your approach is pretty ingenious. So a few points and issues. The main thing here is that I can't see this being useful for user, at least at the moment, but is clearly useful as a developmental tool. So, maybe we should place a README in the sim folder to state its developmental and experimental use, or make another official Grbl group repo for GrblSim (Simen, any comments?). Secondly, I think that the simulator needs to be completely hands-off to the main Grbl codebase. The float changes are fine by me and typedefs would fix this too, but you added a function in stepper.c to get stepper time. Instead we can use the stepper's timer calls themselves with a dummy function to compute them independently for the simulator. Perhaps, this is how we can extract all the data we need, with these dummy functions; i.e. stepper pulse data. So, how do you envision this interfacing with external UI programs? Would the simulator output (step, location, state) data via stdout or some text file? Would it be in some kind of pre-defined data structure? |
|
Ok, the README is a good idea. I'll fix a commit with all the changes discussed and try to rebase for an automatic merge. |
|
I just tried running it and it never prints any stepper positions, seems it never gets to calling the stepper interrupt, what I'm I missing? |
|
It's beta. There's much to be done and worked out, but this is more of a proof-of-concept than anything else. If you have any suggestions on what it should do, it's most welcome. |
|
I'll definately have a better look at it later, it seems the way it has been implemented could also be used as a simple way to port to other mcu's with out changing the avr main line |
|
langwadt: the stepper position is printed to stderr. I don't know where that goes per default on Mac or linux, on Windows it just goes to the console. You also have to give the time step for printing of stepper position as the first (and only) argument (e.g. 0.01). Omitting this argument means time_step= 0.0 which currently is interpreted as "don't print any info". But there is a bug that causes the position at the end of every block to be printed anyway like |
|
This may prove incredibly useful! I'm in the middle of my family summer vacation, so this is all the feedback I have time to provide at this time :-) |
|
@jgeisler0303: Jens. Just following up. Where are you with this? I'm very curious as it's pretty cool. |
|
Sorry I didn't comment lately. I keep reading the issues though. Really busy with my house before the cold season and less light in the evenings force me to stop for this year. Didn't implement any of the discussed changes yet but didn't forget either. Is it urgent? I will certainly come back to it as I still hope that it could also power the visualization extension of the java Universial-GCode-Sender. |
|
Nope! Not urgent. Just wondering. :) |
|
@jgeisler0303 : I'm working on improving the planner and stepper drivers and I think this would be extremely handy. Do you have any time to update some of this code so I can get started on it? It doesn't have to be perfect. I just need to get pointed in the right direction. Thanks! |
|
Nevermind! I got it working. It's pretty straightforward (and brilliant). :) |
|
Thats good to hear. I still plan on making it work with your latest edge soon. Let me know if I can help you in any other way. I think I have a MATLAB script somewhere that reads the grbl-sim output and plots it. I try to keep up with the issues. ITS BUZZING. How do you manage this? Have you still got a regular work or do you just skip sleeping? You should really get a medal or something! |
|
PS: you've probably already figured it out, so just in case:
|
|
Lol. Sleep? Who needs sleep? :) I've been lucky to have a good amount of freetime recently with my fiancee in graduate school and working as well. When she's studying, I work on Grbl. Who knows when the freetime will stop, so hence the hard push to get this stuff done. Anyhow, been concentrating on getting the stepper algorithm fixed/upgrades, so I haven't been able to play with it these last days. Mainly, because it can't simulate the actual process time of the AVR during the step interrupts, but I imagine I'll use it when the planner gets the same treatment. |
|
@jgeisler0303 why not actually implement NVS (EEPROM) with a file, instead of having the user always add $* to the beginning of their test G-code? I mean, you already hooked/replaced the eeprom.c functions, why not go all the way and make it useful :-) |
|
@csdexter That sounds like a logical next step. I really made it run bare bones and then stopped development. Nice to hear that you cloned it. I have to take a look at your fork. Did you adapt it to the latest grbl edge? |
|
@jgeisler0303 I did not clone your simulator, but developed a full HAL to make porting to other architectures easier. The first HAL implementation was for the AVR and the second for the host (i.e. POSIX machine on which you compile), which I extensively used for debugging and observing the way the code works. All credit goes to you for sparking that idea -- it's many many times easier than making simulavr work and then debugging the code the traditional way (gdb & Co.). My EEPROM code (in the host HAL) is here and the "native" (AVR) version is here. My fork is somewhat behind the official code here for strategic reasons: I intend to implement a few things differently than the way they're implemented here. |
code very messy but tested
|
Just pushed a relaunch of the simulator that runs with the latest edge of grbl. It needs no modifications of the original files but does hack into planner.c and protocol.c via injected includes at compile time (see makefile). |
|
Awesome, Jens! This is really cool stuff. I'll go ahead and merge it and add a read me to the sim directory to let people know what it is. I'm a little out of commission for a few weeks, as I'm working on getting my workshop finally setup, but I do have an idea with making the planner more efficient. It's based on your idea that you had about a year ago. I've fleshed it out some and would like to get your input. It's in a Matlab based simulator now. Can I send it to you? |
|
Wow, thanks for merging. Now I really have a reason to tidy up the code :-) Another lane I have in mind is to write a java GUI for viewing the
|
|
The simulator works fine for preview in my (very fresh) frontend: |
|
Nice! |
|
C++, VS2010 |
|
open source？ |
|
not yet, too many features missing (even for my own use) like jogging, length-sensor... |
|
mmmh Windows unfortunately... |
|
Hello JKSoft, if you are thinking going open source you could use QT for example to Thanks, On 2013-01-28 10:29, JKSoft wrote:
|
|
Nice！ |
I don't know anything about Linux.. |
|
On 2013-01-28 10:51, JKSoft wrote:
Regards, PS: I used QT only one time and someone told me he was able to compile |
|
@JKSoft : Very sweet! I'm glad you got the simulator integrated without too much difficulty (I hope). We were hoping that someone would take up the new code and apply in a new cool way, as most of us are quite busy recently to keep working at this. As for QT, I think if you can share your C++ source on Github, that in my mind would be good enough to get people who do know QT or Java to see how you installed it into your GUI frontend. Good commenting goes a long way. This would definitely help everyone I think. |
No Problem, just had to install MinGW because VS could not compile it (as documented).
That's the way i would prefer, Github itself is completely new for me... |
|
Realtime preview is possible too. |
|
I've played with QT for the first time and put my frontend here on Github. |
|
@JKSoft, do you have also a runtime file to download? i like to try it? |
Hi fellow maintainers,
I finally managed to finish the grbl simulator with comments and tested it. The changes may seem immense but grbl really only changes in one place: the execute_runtime is moved to a separate module, so that I can overwrite it for the simulator. All the other grbl files are only changed to use float declaration instead of double (I didn't find a noninvasive way of telling gcc to compile the double like avrgcc does).
The rest of the simulator is in the new directory 'sim'. The simulator uses as much code from grbl as possible and should work with many changes to grbl without touching it.
It is built by calling 'make all' in the 'sim' directory (only MinGW on Windows supported at the time but all other platforms should be straigth forward since its all pure c).
grbl_sim takes commands from stdin until an EOF is encountered. It resonds just like grbl does plus giving info about newly created blocks on stdout. On stderr it gives info on the stepper position. This can be configured by a commandline argument (just a float number) that tells the simulator the time step for printing the info.
The stepper is simulated so that the buffer is always maximally full except when plan_synchronize is called.
What do you say?