RE: My turn getting a Core 1+ working
For the Buddy camera, where is it installed? I don't have one, but instead would like to install an RPI camera. Just looking for a spot to install it. I have one running with OctoPi, just need to find a spot to hang it.
The camera goes into the front/left/upper corner of the enclosure. It's attached to the inside of the metal frame by magnets, which can be a bit fiddly (and some users find the holding force to be on the weak side).
There is a community-designed enclosure for an ESP32 camera in the same style. I have printed that and it works fine -- but the ESP camera struggles at higher temperatures. https://www.printables.com/model/1205313-prusa-core-one-esp32-camera-case
RE: My turn getting a Core 1+ working
I found something on printables.com that holds an RPIcam module. Curiously, the model doesn't tell you what orientation to print it in. My first attempt failed when one of the organic supports fell over. It simply detached and toppled over. First time that's ever happened to me, on any print. I tried something different and got a print to work in PETG. It's not bad, but the camera can't see the front right corner. I may redesign the model, but for now, it's lots better than nothing.
I routed the flat cable out the top, underneath the top acrylic plate. This made me have to place the RPI on top of the printer, because the cable wasn't long enough. For the moment the RPI4 and SSD are sitting on some pink bubble wrap stuff to give it a thermal barrier from the printer. I may hard mount it later. It might fall off the top if not secured, simply due to the printer vibration.
RE: My turn getting a Core 1+ working
More strangeness. First off, things are a lot more awkward, which doesn't feel like an improvement. Not keen on the chamber heating delay, even for PETG. Yeah it waits. And so do I. There should be a better way of turning off the wait than editing gcode. I know what to do, but why on earth should I have to remember to edit it, every time? For a little part?
But this bugs me a lot. I moved the Z axis using the display panel Control menu. Afterwards, it seemed to forget where Z home was. When I started a print, via serial, the printer went in the opposite direction of home. And it faulted. Come on, you can't forget what direction Z home is. IT'S ALWAYS UP!!! Yeah it went down and floundered about and generated a big fat red fault. Had to reset the printer. Sorry, that's amateur. I'm saying that as a person who programs. What ever direction it is, CW or CCW, up is always the same. It doesn't change. But the SW is loosing track of up and down. Because of the red screen fault it wrote bad stuff to memory and suggested re-homing. It took two tries to home. It should never have faulted in the first place. Home for Z is up. Always.
This is not a good user experience. We should be able to do better. I want Prusa to succeed, and I have supported them over the years from the MK3 and following the upgrade path up to a Core 1+. But dudes, the direction of Z home, ie Z=0, is up now, not down. Fix your code, that's a bug...
RE: My turn getting a Core 1+ working
When I started a print, via serial, the printer went in the opposite direction of home. And it faulted. Come on, you can't forget what direction Z home is. IT'S ALWAYS UP!!! Yeah it went down and floundered about and generated a big fat red fault.
That's not something I have ever experienced. A print always starts with a homing sequence, and of course the printer always knows the directions towards X/Y/Z home. But your print start sequence is different from mine. I either send print jobs via Prusa Link (WiFi), or sometimes reprint from the front panel if a print file is already on the USB stick.
How exactly did you "start the print via serial"? Was the gcode file itself already on the USB stick, and has it printed successfully before? What commands did you send via serial?
RE: My turn getting a Core 1+ working
I use Octoprint running on an RPI4. Been using it for 4 years now. The Octoprint is connected from the RPI4 USB to the XBuddy board USB, just like I used in on the MK4S. Since I upgraded my MK4S to the Core 1+, it is the same board.
After inserting the filament, the platen lowers. I had wanted to lower it further to check the build plate dimensions. So I did that from the Core 1+. Then I uploaded my file to Octoprint and clicked the start print button. To my surprise, the platen went the wrong direction in the homing sequence. In my humble opinion, that shouldn't happen. It should go up, perhaps timidly, but it should always go up and touch the load cell eventually. But it went down and stalled at the bottom and generated a red unrecoverable fault. Really, that just shouldn't happen in a properly coded machine. That's indicating a major bug.
I know, I've coded my own electronic lead screw for my lathe... The critical directions, like up is always towards z=0 never change, no matter what. I control a stepper and take in information from both rotary and two high resolution linear encoders. (1um resolution). Anyways, I'm just plain surprised really.
To further diagnose, I could go back to sneakernet and use a USB stick, but honestly that's just going backwards. And frankly, it's slower. With Octoprint I can view the platen, monitor the temperatures and see the head movement, both visually and via a live gcode head position rendering. Perhaps Prusa can finally do this, but I'm not really wanting to work at the change, if the abilities are similar. If the Prusa software for remote access was superior, I'd consider it. For me, printing is not the hobby. Printing for me supports my other hobbies, like machining and prototyping. I just want the printer to work, and work well, without a whole lot of very detailed user input. It may go against the grain here, but I'd like think of the printer more as an appliance that just works, if I enter reasonable parameters.
RE: My turn getting a Core 1+ working
Bruce, there are some situations where the bed does move down by design -- but not as part of the regular initialization before a print. When powered on, the Core One does not automatically home, hence does not know where the bed is. To load and unload filament, the firmware wants to bring the print head to the front, to provide a "relaxed" bowden tube. And to make sure that this XY movement does not damage the print bed, the bed is moved down a bit before that.
One can debate whether that is a smart implementation or whether an automatic homing should be triggered instead -- either right upon startup or before the filament loading. I assume Prusa's logic was that a prior print might still be on the print bed, hence they did not want to auto-home in these situations. Hence they opted for the "safety move" in the opposite direction. Annoyingly, the firmware does not seem to remember that it has already made such a safety move, and may do more of them later, e.g. fur further filament loading/unloading attempts.
But the initialization sequence for a print always does include the homing, starting with the Z axis. I have never seen it move down. Hence I am wondering whether some other action (maybe related to filament changing?) is triggered by your process of starting a print:
- It could be a Gcode command in the print file -- hence my question whether the file prints correctly under other conditions, e.g. when you start the print from the front panel.
- Or it might be sent by Octoprint as part of transferring the print file -- hence my question what commands get sent over the serial line.
I don't think you answered those questions yet. Please look into these. There must be a reason (and an avoidable one) for the unusual behavior of your Core One.
RE: My turn getting a Core 1+ working
I'm not sure how to determine if Octoprint sends additional information to the printer, besides having an auxiliary serial monitor on the line. This is a bit beyond where I want to be. (Trying not to make printing a hobby or sink hole. Have enough of that in my life already.) The gcode is inspect-able, but I'm not fluent in the commands, especially any Core 1 or even Prusa specific codes. Also this gets somewhat into the finger pointing area, is it us or them. My issue is I'm not an expert in either, nor do I really want to become one. I just want to be a happy user, with few or no problems with the product.
Clearly agree there's a reason, stuff doesn't just happen, at least with programs. Unexpected results can simply be bugs, or tolerated "things that happen sometimes, but we don't know why yet", or even, "gee we never have seen that before".
If there are some gcodes that might be interesting to search for in my file, I can do that. I don't particularly know what they might be. The gcode is uncompressed and 3.3MB. I have the feeling that the RED fault and the consequent reset may have altered things, so forensics might be less fruitful. Perhaps the Core 1+ has an error log that can be inspected. I'm willing to spend some time on this, but not many days worth. I just wish it wasn't quirky, so I could get on with doing things.
The print in question was something I designed in the MK3S days. There's no longer a draft mode, so I re-sliced it, making sure I had changed everything to the Core 1. It printed very nicely, save for a tiny spot on the first layer (and perimeter) where the filament had lifted from the plate. Could have been dirty there, but it was about 3mm x 1mm and only one layer. Doesn't affect the use of the part, which slides over 38mm 80/20. I use these pieces to hold AXA tools for my lathe. The tool holders are held by the dovetail. I can attach the gcode file if desired.
RE:
I think the first step should be to differentiate whether the unexpected behavior is due to something in the print's gcode file or something Octoprint transmits. Do you always get the downward movement when you print via Octoprint? When you start the same print from the USB stick via the printer's front panel, does it print without the wrong movement? This is not about fingerpointing, but about identifying and fixing the problem.
If this A/B testing points to Octoprint -- I have never used Octoprint, but supposedly you can review its template files to see what it transmits before a print job. See the quote below. (AI-generated, no warranties. 😉)
If the A/B test points to the print file itself (i.e. it always or sometimes triggers the wrong movement event when started directly from the printer) -- yes, please post the gcode file here.
Based on documentation from OctoPrint, the application allows users to define custom GCODE scripts that execute at specific events, such as before a print job starts. The script named "beforePrintStarted" runs immediately before initiating a print job and defaults to being empty, meaning OctoPrint does not add any initialization code by default in this script. Other scripts, such as "afterPrinterConnected," also default to empty.
To check for any custom initialization code in your OctoPrint instance, navigate to Settings > GCODE Scripts in the web interface and review the contents of the "beforePrintStarted" script (or others like "afterPrinterConnected" if relevant to connection behavior). For online reference, the official OctoPrint documentation details these scripts and their defaults at https://docs.octoprint.org/en/master/features/gcode_scripts.html
RE: My turn getting a Core 1+ working
Foo, lost my editing. Anyways, my Octoprint scripts for before and after print are empty, so I don't think that's a cause.
I just edited my gcode to get rid of the G29 G in the beginning, that's a time waster, at least for debugging. I have printed over a dozen of these prints without G29 G, and they were all successful, in an open air printer. I'll try again. First I need to wash the plate, it's kind of weird looking, with shiny areas and micro fibers on it. I will simply check to see if the issue is repeatable doing roughly what I did yesterday. If not repeatable, then I don't know what to think.
If I recall correctly what I did yesterday was:
- Install filament, wait for completion
- Lower the platen - I had wanted to measure something. I don't need to measure anything now, but that's what I did yesterday
- Start the same print from Octoprint - but now without the G29 G command
See what happens. Reasonable plan for the moment?
RE: My turn getting a Core 1+ working
If I recall correctly what I did yesterday was:
- Install filament, wait for completion
- Lower the platen - I had wanted to measure something. I don't need to measure anything now, but that's what I did yesterday
- Start the same print from Octoprint - but now without the G29 G command
See what happens. Reasonable plan for the moment?
Sounds like a plan. But just to make sure: I assume that there is a G28 command a few steps before the G29? G28 is what triggers XYZ homing, so you should already see the bed moving up and touching the nozzle at that point. If it moves down instead, it must be something that happens before the G28.
RE: My turn getting a Core 1+ working
Six lines prior to the commented G29 G command there is a G28 "home all without mesh bed level" command. Should be good. I'm amazed that there's over 2000 lines in the file which are merely thumbnails, all of which is prior to any gcode commands. Took a while just to find the start of the gcode!
RE: My turn getting a Core 1+ working
Even though I commented out the G29 G command, the temperature of the print head was lowered to 130C for a short while, and I had to wait 2 minutes for the chamber to heat! Here is the Octoprint temperature graph showing this. It shows there was a command to lower the temp of the print head.
On the other hand, the printer did what it needed to do, and didn't get mixed up. When I started the print, (after moving the platen down from 100mm to 110mm,) and it homed correctly. So it didn't repeat the bad behavior. So much for debugging. It does take quite a while to home X & Y though, lots of bumping. Think their algorithm isn't that great.
RE: My turn getting a Core 1+ working
Even though I commented out the G29 G command, the temperature of the print head was lowered to 130C for a short while, and I had to wait 2 minutes for the chamber to heat! Here is the Octoprint temperature graph showing this. It shows there was a command to lower the temp of the print head.
On the other hand, the printer did what it needed to do, and didn't get mixed up. When I started the print, (after moving the platen down from 100mm to 110mm,) and it homed correctly. So it didn't repeat the bad behavior. So much for debugging. It does take quite a while to home X & Y though, lots of bumping. Think their algorithm isn't that great.
The printer wants to perform the bed probing at a defined nozzle and bed temperature. Was it really that chamber that needed to heat up, or the bed?
The head-bumping wants to determine a very precise XY homing position -- not sure why that is needed, presumably only to allow exact continuation of a print in case of a power failure. Nevertheless it should not be excessive: "Right, right; front, front; right, front, right, front, right, front, right, front" if I recall correctly. If your printer takes much more than that, you need to align the X gantry and tension the belts: https://help.prusa3d.com/article/adjusting-belt-tension-core-one-l-core-one_845048
RE:
Even though I commented out the G29 G command, the temperature of the print head was lowered to 130C for a short while, and I had to wait 2 minutes for the chamber to heat! Here is the Octoprint temperature graph showing this. It shows there was a command to lower the temp of the print head.
On the other hand, the printer did what it needed to do, and didn't get mixed up. When I started the print, (after moving the platen down from 100mm to 110mm,) and it homed correctly. So it didn't repeat the bad behavior. So much for debugging. It does take quite a while to home X & Y though, lots of bumping. Think their algorithm isn't that great.
The printer wants to perform the bed probing at a defined nozzle and bed temperature. Was it really that chamber that needed to heat up, or the bed?
The head-bumping wants to determine a very precise XY homing position -- not sure why that is needed, presumably only to allow exact continuation of a print in case of a power failure. Nevertheless it should not be excessive: "Right, right; front, front; right, front, right, front, right, front, right, front" if I recall correctly. If your printer takes much more than that, you need to align the X gantry and tension the belts: https://help.prusa3d.com/article/adjusting-belt-tension-core-one-l-core-one_845048
You are correct, the bed wasn't hot enough yet. Ok that makes sense.
As for the X gantry and the belt tensioning, umm, how many times do I need to do this? Did that sequence (more than) twice already... Doesn't seem dimensionally stable. I suppose the belts could be relaxing, or have stretched. I'll check the XY gantry again to see if it is misaligned again. If I move this printer again, like to rotate it for service, do I have to redo the gantry stuff?
RE:
As for the X gantry and the belt tensioning, umm, how many times do I need to do this? Did that sequence (more than) twice already... Doesn't seem dimensionally stable. I suppose the belts could be relaxing, or have stretched. I'll check the XY gantry again to see if it is misaligned again. If I move this printer again, like to rotate it for service, do I have to redo the gantry stuff?
In my experience, it is quite stable once you get it right. I recently carried my printer upstairs and later back to the basement, and the gantry and belt alignment did not change significantly. Maybe there is some initial settling-in however; my kit has been running for 9 months now.
Did you follow the most recent instructions (link above)? I am not sure whether they are also incorporated into the build instructions already. It is important to first ensure that the gantry is orthogonal to the Y axis -- i.e. hits both end stops in the front at the same time -- while the belts are fully relaxed. Then tension the belts, making sure you always tighten them symmetrically. Earlier versions of the instructions suggested using asymmetrical belt tension to force the gantry into alignment, but Prusa have changed their mind about that and it is now a no-no. Final adjustment is best done with the "Manual Belt Tuning" stroboscopic wizard in firmware 6.4.0; much easier than the earlier sound-based method.
RE: My turn getting a Core 1+ working
There were no obvious instructions at all to do anything post assembly. It sure wasn't in the online build instructions. They left you with an assembled printer, and nothing else. I had to search elsewhere when things went awry. I "twisted" the gantry to have both sides line up with no tension. I then did the acoustic tuning, which is hard to perform in my location. I am next to a main street, and cars going by screw up or mask the belt tones. There was no mention of using the stroboscopic method at all.
My printer has only been "alive" since early January, so not even 8 days assembled. Thanks for the tip on stroboscopic tuning.
RE: My turn getting a Core 1+ working
I have a question about what to look for. My gantry is fine. Stroboscopic setting said I need to do nothing.
But I don't know exactly how the belt is supposed to behave. I just looked for maximum smooth deviation of the belt. According to the tuner, I need zero adjustments. No turns.
Prior to this, during homing it was doing a bunch of banging, far more than two love taps. I'm confused. Seems unnecessarily noisy to be fully set up, but maybe my expectations are too high.
RE:
During belt calibration you are looking for the largest amplitude of the belt movement. The apparent movement is with about 2 Hz, since that's the frequency difference (beat frequency) which the tuning wizard maintains between the belt excitation and LED strobing. The way I read your description, that is what you were already looking for.
So the observed resonance frequencies are in the range which makes the tuning wizard happy, and the gantry still touches both end stops at once (when you turn the motors off and pull it forward)? Then you are "entitled to" an XY homing without excessive banging.
You could try re-running the "Homing calibration" from the menu. While I have not seen it documented anywhere, I believe it measures what the measured current pattern of the stalling motors looks like ("Stallguard" sensing via the Trinamics motor drivers), and uses that in the homing process later.
RE: My turn getting a Core 1+ working
During belt calibration you are looking for the largest amplitude of the belt movement. The apparent movement is with about 2 Hz, since that's the frequency difference (beat frequency) which the tuning wizard maintains between the belt excitation and LED strobing. The way I read your description, that is what you were already looking for.
So the observed resonance frequencies are in the range which makes the tuning wizard happy, and the gantry still touches both end stops at once (when you turn the motors off and pull it forward)?
YES.
Then you are "entitled to" an XY homing without excessive banging.
You could try re-running the "Homing calibration" from the menu. While I have not seen it documented anywhere, I believe it measures what the measured current pattern of the stalling motors looks like ("Stallguard" sensing via the Trinamics motor drivers), and uses that in the homing process later.
The gantry touches practically equally on both sides when pulled from the center. I'm sure it isn't perfect, I didn't use feeler gauges, but it's pretty good, way under 1 mm, maybe less than 0.25 mm.
I was looking for maximum deviation of the belt at the lowest frequency. The head was to the right. So I was looking for 1/2 cycle of a sine wave, with maximum apparent deviation. I was not looking for multiples of cycles, because, I think that is a harmonic of what we want. But I have not seen a physics like description of what exactly we should see, so I could very well be wrong.
RE:
This video shows the moving belt and what to aim for. The relevant part begins at 2:40: