Questions and chit-chat

[leptun]

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?

[vintagepc]

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.

[leptun]

@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.

[vintagepc]

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!

[leptun]

@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.

[leptun]

@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.

[vintagepc]

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 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. 👀

[vintagepc]

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!

[leptun]

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...

[vintagepc]

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)

[leptun]

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)

[vintagepc]

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.

[leptun]

@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.

[vintagepc]

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.

[3d-gussner]

Thanks for inviting me.
I am Waldi aka 3d-gussner.

[vintagepc]

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!

[leptun]

Wonderful news! Where are you planning to make a post about the project?

[vintagepc]

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)

[DRracer]

@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.
The best timing to promote your huge effort is with FW 3.9.1 and largely repaired Linear Advance 1.5, which wouldn't be possible without the SIM and direct insight into what is going on in the algorithms during printing. @wavexx , what do you think?

[DRracer]

@vintagepc - a short notice:

• cloned with submodules
• apt install libelf-dev libsdl-dev freeglut3-dev
• opened CMakeLists.txt in QtCreator 4.13b1
• compiled like a charm with gcc-10.1.0 ;)
  It runs, however I'm still having problems with the boot process taking about a minute. The "P" and "E" letters are rotating, but nothing is happening. It is standing at pBoard->WaitForFinish(); and some other threads are possibly waiting for UART. At least I can debug it nicely with full comfort in QtCreator ;) . I'll let you know if I discover something (if @leptun isn't faster as always :) ).

[vintagepc]

@vintagepc - a short notice:

• cloned with submodules
• apt install libelf-dev libsdl-dev freeglut3-dev
• opened CMakeLists.txt in QtCreator 4.13b1
• compiled like a charm with gcc-10.1.0 ;)
  It runs, however I'm still having problems with the boot process taking about a minute. The "P" and "E" letters are rotating, but nothing is happening. It is standing at pBoard->WaitForFinish(); and some other threads are possibly waiting for UART. At least I can debug it nicely with full comfort in QtCreator ;) . I'll let you know if I discover something (if @leptun isn't faster as always :) ).

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 FirmwareDebug.md for info how to make the dump)

[DRracer]

@vintagepc sorry, my bad, no firmware (parameter -f). Now it runs well, thanks for your hint.

[vintagepc]

No worries. I added a note to the README to that extent, you weren't the first, and won't be the last ;)

[wavexx]

On Sun, Jul 26 2020, DRracer wrote: @wavexx , what do you think?

I think it would be awesome if possible!

[3d-gussner]

https://twitter.com/MarlinFirmware/status/1287259911303442432

[vintagepc]

Heh, that explains the giant spike in traffic yesterday 😁

[vintagepc]

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. :)

[vintagepc]

Welp, I posted about it in the forums.
Time to brace for the masses 🤣

[GilesBathgate]

Hi, I tried out this project. I couldn't get selftest working in various scenarios, or calibrateXYZ, I can log some issues for these. My question is have you considered being able to simulate hardware failures or construction issues such as slipping belts, bed/frame skew, or an unlevel heatbed?

[vintagepc]

There are quite a few fault conditions that can be simulated, yes - such as motor stalls, thermal runaway/thermistor shorts, custom bed mesh, etc - Have a look at the scripting options for a given printer:
https://github.com/vintagepc/MK404/wiki/Scripting

A common problem with selftest and XYZ calibration is forgetting to toggle the presence of the steel sheet (key y ) so that the printer can find the calibration points.

Does that help?

[GilesBathgate]

@vintagepc it seems to be clang. When compiled with gcc/g++ the selftest works. I thought this might be due to #339 since clang could be fussier about the attribute, and also this post seems to suggest it only works when declared after the struct keyword https://stackoverflow.com/questions/13688625/how-to-declare-packed-struct-without-padding-for-llvm/25532933 however changing these doesn't seem to help.

[GilesBathgate]

Sorry, you wanted to know if the cursor on the LCD moves when you press the keys? No, it freezes, the > is stuck.

[vintagepc]

Thanks,

Hmm... the blank lines in the terminal after the output are interesting. That almost seems like the focus is wrong and the enter keypresses are going to the terminal instead of the application window.

[vintagepc]

What version of clang are you using? I'll see if it's available for my distro and see if I can reproduce the issue locally

[GilesBathgate]

$ clang -v
Ubuntu clang version 12.0.0-3ubuntu1~21.04.2
Target: x86_64-pc-linux-gnu
Thread model: posix

[GilesBathgate]

The blank lines in the terminal after the output are interesting. That almost seems like the focus is wrong and the enter keypresses are going to the terminal instead of the application window.

Thats my bad, I was just trying to get anything to respond.