This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
Questions and chit-chat #12
Comments
|
You're welcome! 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. 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. |
|
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,
|
|
@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? 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 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 prusa3d/Prusa-Firmware#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. |
|
Yeah, that's definitely a looooooooooooong way off. 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. |
|
@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. |
|
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. |
|
Welcome aboard! |
|
@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've bumped up what I have so far along with a few readmes and whatnot. |
|
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 :) |
|
Yeah sorry :) |
|
Invite sent! |
|
"Who the hell are all these random people mentioning me on 3d printing stuff? " 🤣 |
|
oh, now I understand ;) . Thanks for inviting me into the simulator. |
|
Welcome aboard! |
|
@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. |
|
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) |
|
Yes on the last point... I've seen that more general users often lose interest if you share a project too early because they don't have time to deal with the constant updates or things being not functional yet. I'll reach out to Scott and Gina :-) |
|
It's a good point. I generally simply don't announce it ;) |
|
Welcome aboard to @foosel 😄 🐙 |
|
Hi there! Will have to give this a test soon, looks awesome! |
|
@foosel moin moin, I used it very often to troubleshoot things and used Octoprint for communication. We could troubleshoot few issues in the Prusa Firmware with Octoprint. |
|
Btw, I know on linux simavr creates a tty. I have zero experience on windows, but does it create a virtual com port? |
|
You have to build it with Cygwin on windows. I imagine that if you were to make a virtual COM port in Win you could pipe it through to the PTY to get a connection. I think the project (and simAVR, more importantly) use too much underlying linux stuff to ever be able to build a native windows version. |
|
Welcome aboard to @thinkyhead! |
|
I know I've been saying this for a while but I think we've got all the major functionality out of the way... I think we are in good shape to flip the switch to public in the very near future once we wrap up the MK3 variant work! 🎉 |
|
We are public! Note this decoupled the previous fork(s) you may have had to private repos, so you will need to create a new fork and/or rebase your changes onto the current repo. |
|
Wonderful news! Where are you planning to make a post about the project? |
|
I haven't thought that far ahead, I figure I might just let it gain its own momentum. I might post about it in the PR forums. (I don't do social media like reddit etc, so my exposure avenues are somewhat limited). Who knows, maybe someday we'll get featured on a Prusa livestream or blog post... 🤣 @DRracer (wink wink nudge nudge) |
|
@vintagepc great news! I'll talk to our Content team about the (now public) MK3SIM, in fact I already got some questions about its state and whether it will get public one day. |
|
@vintagepc - a short notice:
|
Interesting, please feel free to start a separate issue thread so we can debug this without other messages getting interleaved. (You did load a firmware to flash at least once with a -f flag or PS/avrdude, right? Otherwise you might just be bootlooping the bootloader. Don't think this is the case though, sounds like it does eventually finish the boot process) The wait state sounds about as expected, WaitForFinish() is basically a thread_join that returns when the AVR shuts down. Most of the other threads are indeed just serial helpers. It might be useful in this case to inspect the avr->pc value while it's bootlooping and reference that back to an objdump of the .afx file to see in what function it's stuck. (Board.h::RunAVR()). See |
|
@vintagepc sorry, my bad, no firmware (parameter -f). Now it runs well, thanks for your hint. |
|
No worries. I added a note to the README to that extent, you weren't the first, and won't be the last ;) |
|
On Sun, Jul 26 2020, DRracer wrote:
@wavexx , what do you think?
I think it would be awesome if possible!
|
|
Heh, that explains the giant spike in traffic yesterday 😁 |
|
I've enabled a wiki for the project, seems like a useful addition as a place to document technical info as required. Feel free to add/edit as you see fit, hopefully it will morph into something with a clearer direction as we find uses for it. :) |
|
Welp, I posted about it in the forums. |
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
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?
The text was updated successfully, but these errors were encountered: