Zero Mods

0 views

Skip to first unread message

Florio Bessinger

unread,

Aug 4, 2024, 3:20:19 PM8/4/24

to elalosab

Thenafter the firmware is flashed, enable the setting for 2nd USART in the settings. This also disables the onboard USB port.

Note that this can only be done when there is nothing connected to the Einsy's USB port.

On the RPi3 and Zero, the Bluetooth gets the higher performance serial port, and the GPIO gets bumped to a lesser performing setup. For more info check out:

-gpio-serial-port-raspbian-jessie-including-pi-3/

One word of caution. I am pretty certain that I remember hearing Josef mention in a video that there would need to be some modifications to Octoprint to make it compatible with the new additions introduced on the MK3. Power Panic obviously isn't going to work. Anyone remember this, or have extra insight?

Thanks man for this info. I ordered my Pi zero right after ordering my MK3. The MK3 should be coming next week probably. I already have octoprint running, that wasn't difficult, but didn't know about the the bluetooth and higher performance serial port, so I can make these adjustments.

Also note that you really should do a shutdown in Octoprint before switching off the power to the printer. While I haven't ever suffered corruption of an SD card in a Pi that had the power yanked, others have. When the power is cut, there is not enough time for the Pi to go through a proper shutdown. The green light on the Pi will go off wen it is full shutdown.

The camera is going to be a little trickier. I forgot the camera port on the Pi Zero is smaller than the larger Pis. So the meter long cable I have will not work. 30cm is the longest Pi Zero camera cable I can find, which will not be enough. Adafruit makes and adapter that could splice a regular Pi camera cable to a Zero cable.

I had previously been working on mounting a Pi Zero and camera to the left side Y axis pulley. I may go back to that idea, and wire the Pi into to Einsy, rather than directly. Might be cleaner than splicing together camera cables. Would also make the Pi much easier to access.

Well I got everything "working" after my dumb self initially installed the pi upside down on the mount. I can say that is a real pain in the ass not to have an access door to the back of the electronics case. Hopefully someone will design an improved enclosure soon. It would also be nice to have a shutdown button to make safe power off easier and faster to accomplish.

Anyway Octoprint can connect and communicate however the connection is very unreliable. I see checksum errors sending basic commands, and eventually the print crashed. I think this occurs when a corrupt command makes it through with a checksum that passes (the gcode checksum algorithm is very basic and collision is easily possible). Some people were getting crazy extrusions or other strange behavior, so it's not just me.

So some work still needs to be done. I am not honestly sure if it is the Einsy firmware or some configuration of OctoPrint that needs the tuning, although I suspect the firmware is the first issue. I am holding for additional feedback at this point.

Yes I did try to print through OctoPrint with Pi Zero W directly attached and had major trouble. The serial communication does not yet appear to be reliable. I do not have a lot of time to debug if the issue is related to issues on the serial comms of the Pi or the Einsy, but I did set the configuration as noted earlier regaridng swapping the bluetooth and hardware UARTs. I had seen elsewhere something about disabling the bluetooth serial profile entirely but, again, I havent had time to debug and I don't want to keep my printer offline that much as I have a lot in the queue to get printed.

I'm going to try repetier-server for the first time today or tomorrow, I'd like to keep the crash detection on.

Don't bother, Repetier-Server suffers from the same bad data problems as Octoprint. Seems like this is a fundamental serial comms problem between the Pi and the Einsy.

Correct; disabling the stepper error detection will have no effect on this issue. If you carefully watch the octoprint terminal during a print (or look at the log I posted) you will see the einsy requesting command retransmits because of checksum mismatches. The crashes and other problems are happening mainly because every once in a while a corrupted gcode command will happen to have a valid checksum and the printer will dutifully execute it. The checksum in this case is a very simple algorithm that produces a checksum number in the range 0-255, and in the case of thousands of errors occurring over the flaky serial link, some lines are bound to have corruption and still pass the checksum test.

I didn't have any issues while running Octoprint externally on a RPi 2. I did have a stall while using the Zero connected to the Einsy. Later that day I had a stall and a layer shift while printing from the SD card, and the Pi was powered off. I would have thought the Einsy would have detected the shift, I wasn't using stealth mode.

It is a little discouraging the Prusa has been silent on this. I can understand if it isn't ready, but they are releasing the STL for the spacer, and included the pinout in the most recent Handbook update. The Handbook makes it should like you just slap the Pi onto the Einsy and go, but that isn't the case.

i've got my new rpi (after i burnt one) and regarding Linux i'm pretty much newbie... as a result, i'm stuck at adding "/dev/ttyAMA0". ... where to add this line? I guess because of this line is missing (somewhere) in octoprint i don't have any serial ports available...

Thanks!

Is it a bug or a feature that scavenging skills/perks etc make no difference to the block damage of salvaging a killed robot. Even testing the Dev: Wrench does the same amount of salvage as T6 ratchet or driver. Or is there a new late-game tool that works better at this?

I think Zilox mentioned the best place to post these reports are in his discord, so they get the proper attention. Though I am unsure if that is a bug, you never know he may want salvaging to be slower with the robots.

The fuel system works very different in the base game compared to some other mods like UL. Gas cans are crafted in stacks of 5, so you will end up with quite a large number of gas cans. Fueling a minibike for 1000 gas cans is considered low, as a 4x4 in vanilla takes about 10k gas cans to fill to 100%

Craft from storage is not something I'm that interested in adding, and most likely won't be added any time soon or if it is added it will likely be unlocked through special storage containers or other progression paths.

I was reading about this exact same issue in the DZ Discord channel. It appears that while the person was using the most up to date V1.2.4 of Disctrict Zero, they were not using the most up to date A21.1(b16). Since revisions in DZ are specific to the 7D2D version, this was an important step. Can you confirm you are fully up to date with 7D2D?

Yeah, I want to second what @arramus said. I have had a number of players mention this to me with other mods as well. At least half that got back to me indicated that when they checked the correct alpha version (stable or exp) that was required, they were able to fix the problem. I believe this is the same problem with players only getting buried treasure quests from the traders. Same solution.

I'm watching a couple Youtubers play this and I can't help but think that in an overhaul where all live creatures are gone and the robots have destroyed everything, this should be a wasteland-only modpack. Maybe wasteland and desert if you want to be kind.

It is fortunate the RWG allows us to set our very own parameters for Biomes, and it'll be interesting to get your feedback on how a Wasteland only play through plays out with the current setup. Beware those spawn rates and radiated rainfall though if you give it a try.

Biomes will be overhauled into different planets in the future, so there will no longer be the regular 7 days biomes like wasteland, desert etc. Mostly likely the forest biome will stay as earth with some improvements.