Closed leptun closed 3 years ago
You're welcome! Right now it's just you and me (I invited wavexx as well).
I don't have anything in particular lined up for comms, I figured that with a small number of folks we could probably just use issues like a forum thread for notifications and discussion. Certainly once we get going we can look at alternatives (slack, etc) for casual discussion.
As this is a private github repo I'm currently limited to 3 invites, so I'm playing it by ear. If you have suggestions for other folks that might be able to contribute I'm happy to hear. The private nature is only temporary though - mostly because it's in the early stages of bring-up and many of the tasks are serial in nature. Once the firmware at least boots, we can "fan out" and it's easier for multiple people to work on tasks like implementing a piece of hardware without either duplicating efforts or stepping on each others' work.
I don't have any expectations on contributions or anything - I invited folks out of interest in the project and not because I had expectations they would contribute :)
In terms of status I'm hoping to spend a bit of time each evening this weekend some of the weekend to see how far I get, and to clean up what I've got into something consistent and maintainable to push it.
@vintagepc yes, Wavexx just also saw your invite. I’m thinking that maybe 3d-gussner could also be interested in this. I’ll ask him later.
I’m really curious about the stepper implementation. Imagine emulating MK3 hardware completely. What I mean by this is creating actual “hardware” limits for tmc drivers and loading a custom MBL matrix for testing the code and stuff like that. Also, the UVLO can be tested in an environment that is much more controlled than cutting power.
Absolutely! Once we get this going there's very little we won't be able to do in terms of poking and prodding to set up test cases.
I'm also happy to invite 3d-gussner if he's interested. I contemplated dracer as well but I don't have a good sense of whether he'd be interested this early since he's got other priorities.
Also, PROGRESS! (I traced #11 down to an issue with the serial IO handling. Disabling it in the firmware... it boots!
@vintagepc Would it be better if we started smaller? I also want the target to be MK3/S, but maybe it would be easier if we started with MK2.5/S and worked our way up to the other printers.
@vintagepc Also, is anything in the emulator persistent? After a "reboot", do you still have the same EEPROM contents? And as for the W25X20CL flash, I'd make sure that doesn't erase itself every time we change anything in the code.
And @3d-gussner would also like to join this project.
Maybe - though I get the impression the main part is soon going to be just getting hardware modules online and I think that after the initial layout learning curve that should go pretty quick for things in our areas of expertiese, where each bit is a relatively straightforward component. At least in my case my frame of reference is the MK3S and I'm not intimately familiar with the MK2.5S and its bits/pieces. I have more visibility right now since I'm looking at the interfaces and code and mapping it out in my mind, but I think this'll get clearer once I push it up for you guys too.
I'm definitely not opposed to that though, far from it.
Any memory is easily made persistent. The program memory is already - for faster testing turnaround I have it reload the firmware/bootloader each time but that can be disabled. The contents are stored as a .bin file on disk (easily hexdumped for inspection) (you could theoretically program it with objcopy -I hex <firmware.hex> -O binary <flash.bin>
I've been conservative with my estimates on timing, progress has been progressing faster than I anticipated so I may push something up sooner rather than later.
Side note, I think this bringup will also reveal some interesting things in the firmware codebase as well, for example https://github.com/prusa3d/Prusa-Firmware/issues/2582 - Not necessarily things that are broken, but just something that someone should take a second look at.
I sent 3d-gussner an invite. I'm actually really excited for where this is going given I tossed it out as a casual idea; the mind still boggles that I even managed to get it to boot to the main marlin menu in the span of a few days. 👀
Also I think it would be ultra-cool if we could get this wired up enough to the point we could even graphically simulate a print. Would Prusa be the first to have a fully virtual 3d printer? Might even have implications for something like P'licer giving you a toolpath or print animation!
Lofty goals, I know. So many ideas, so little time!
I was also thinking about that, but I think it is a bit too early to even start thinking about those implementations. I agree with you that a live 3D model of the "printer" would be quite useful for some functions. Btw, what's the performance of the emulation? Is it horribly slow? In my case, the fans ramp up to max as soon as I start the hd44780 example in the simAvr source...
Yeah, that's definitely a looooooooooooong way off. On my laptop (from 2013) it feels a bit more laggy than the real thing, but I often have program counter logging on since I'm still debugging early boot stages.
I'm pretty sure the examples are not well optimized, I think the display one basically has a while(true) with no sleep cycles in it somewhere... Also, that example enables VCD traces by default so it's logging a ton of data every 10 usec, IIRC)
You say it feels a bit more laggy... Would it even be possible in the future to speed up the runtime for generating some of the weirder bugs that don't happen instantly? (Aka fast-forward)
I think so. I'm almost certain some of the lag comes from unoptimized things like display draws, I am definitely not a GL expert, I think it updates anytime there's a display write, for example. No reason that couldn't be changed to delay slightly in order to aggregate several character writes. Once we get a proof of concept I think we should be able to get improvements. I haven't gotten to the point of trying to profile stuff yet.
@vintagepc Just saying, when the LCD buffer will get merged into the MK3 branch, we could make it even more lightweight. Just read the buffer in memory for the characters. Only the custom characters should be a bit more interesting. Btw, in my latest push to that PR I also created a "banking" implementation for the custom characters (since we have 11 chars that must fit in 8 cells). With the new implementation, each and every custom character has a dedicated uint8_t value. This means that we could even just edit the font of the drawing program to have our custom characters in the 0x00-0x0F range.
Oh, cool! I contemplating implementing the custom character upload to-spec on the reference display. But as noted in #4 there are some issues with the stock implementation to address first with regards to framing/memory locations.
Thanks for inviting me. I am Waldi aka 3d-gussner.
Welcome aboard! BTW, if folks have any particular issues/hardware they are interested in working on then please feel free to comment on or claim them. I'm hoping to get my exploratory hackery cleaned up in the next few days and then we'll be off to the races!
@vintagepc I’m a bit new to coding outside embedded platforms... How exactly do you make it “run”. I know that is a basic thing, but I’d like to have a basic understanding of what is going on. After that, I can begin to understand how your code works and move on to the W25X20CL task.
Ah, sure. Let me finish pushing up the rest of my assortment of stuff. I just finished templating a basic SPI dummy class to see if I could get it to print out the bytes it's receiving from the AVR. I'll follow up with a readme.
I've bumped up what I have so far along with a few readmes and whatnot. Let me know if you have any questions/issues getting started!
Observation: Partway through the TMC2130 work I think that's part of what's causing it to be sluggish. It's constantly detecting crashes and trying to rehome (even if I cancel the setup wizard)
Github now has unlimited collaborators on private repos - so if you can think of other folks that should be invited to preview/contribute to the project, please don't hesitate to let me know!
What about @dracer :)
@DRracer not @dracer
Yeah sorry :)
Invite sent!
@wavexx I've done this mistake in the past. The only way I noticed the mistake was that the text wasn't capitalized automatically. RIP @dracer for the spam he probably gets whenever someone mistypes @DRracer's name
"Who the hell are all these random people mentioning me on 3d printing stuff? " :rofl:
oh, now I understand ;) . Thanks for inviting me into the simulator.
Welcome aboard!
@vintagepc @leptun please update the doc a bit, it took me a while figuring out I had to clone the simavr from source, copy the cloned MK3SIM into examples/board_einsy (!).
And - which branch is the most recent one? I'm having a compile issues, which has probably been already solved elsewhere:
Einsy.c:381:50: error: ‘TIMER_IRQ_OUT_PWM2’ undeclared (first use in this function); did you mean ‘TIMER_IRQ_OUT_PWM1’?
@DRracer The "documentation" for setting up the build env is this: https://github.com/vintagepc/MK3SIM/issues/26#issuecomment-613130844 We'll write a real documentation later.
I'll update the 'getting started` file with that comment's contents for starters.
Done. Sorry about that- we've been moving pretty fast over the last two weeks so the docs haven't really kept up.
@vintagepc no problem, I know this is an early sprint ;)
This is just too cool not to share... https://vimeo.com/409042050
Edit - also:
(Gif is slower than reality, just didn't transcode well)
Today is a big day... There are definitely still some issues to resolve and features to implement... but I am pleased to announce I've just successfully completed the calibration wizard on the simulator! (Edit: whoa, has it only been a little over two weeks??!?)
@vintagepc great screenshots - I'm slowly catching up with your progress. May be a silly question: is it normal that it takes literally minutes before the "printer" gets from the initial screen?
@vintagepc great screenshots - I'm slowly catching up with your progress. May be a silly question: is it normal that it takes literally minutes before the "printer" gets from the initial screen?
It starts pretty quick for me, maybe about five seconds between starting and the idle info screen being up. My computer's from 2013, so it's not horribly demanding in terms of hardware requirements, I think.
Do you have some details on how you're running it? (hardware, VM, etc) - perhaps that can provide some insight as to what's up. I know some earlier builds were definitely sluggish.
@vintagepc physical machine intel Core2 quad @2GHz running Kubuntu 19.10 ... I made a clean build a few minutes ago. It is just the start, then the simulated printer behaves like a real thing in terms of speed
Hmm, are you running the bootloader with the -b argument? There are some known glitches with the delay timer that might be part of the issue (#75). Based on the docs from Atmel there isn't a substantial difference between FC and PC pwm modes but it seems to be enough to alter the time tracking. (PC PWM isn't implemented in SimAVR)
Additional note: I created a few projects we can start using to track the state of various goals/milestones.
Please feel free to categorize issues as you see fit, the more organized things are the better the end result will be :1st_place_medal:
With or without -b it really doesn't make a difference, it takes about a minute to get into main screen. May be an unoptimized build of the Einsy.elf?
Projects: OK, I'll look into it
Interesting. I wonder if this is a variant of #59 ... I've noticed the opposite a few times where first boot is fast but subsequent boots seem to run more slowly. The MMU was terribly slow for me until I implemented the buttons because it thought someone was holding down the left button all the time - so I'd not be surprised if were missing a part of something that, when uninitialized can result in odd behaviour.
Edit: Also, it might help to do a fresh pull of the parent simavr worktree_test
branch I have and rebuild that with make build-simavr
to make sure you're up to date with tweaks I've pushed there.
@vintagepc Could you please add another person to the project? Try Miroslav.majer@prusa3d.cz . There's a chance that it might not work.
sure, I'll give it a go
Looks like it did not find a github account and sent an invite to his email address :+1:
@vintagepc please contact me via email, we'd like to send you some present for your work on FW 3.9.0.
How do folks feel about an expanded private beta now that all of the tasks in "Functional MK3S" are complete? Anyone specific come to mind?
I think this would be a great tool for Scott from the Marlin team. And Gina from Octoprint, not sure if she has the time but could imagine that she would know some developers who would be very interested in this.
On Tue, Jun 23 2020, vintagepc wrote:
How do folks feel about an expanded private beta now that all of the tasks in "Functional MK3S" are complete? Anyone specific come to mind?
Hard to point out anyone specific, but I second @thinkyhead (Scott) for sure.
I wonder why the "private" beta started in the first place? ;)
Isn’t it better when you surprise people with a finished project? That’s what I would personally do. (Hint for a project I’m working on)
Hi @vintagepc Thank you for inviting me to this project. I've read what you wrote so far in readme.md. I have a few questions: How do you propose that we communicate after you push the first usable source code? Are there others involved in the project?