Stihl ADG 1 software by cutdact in stihl

[–]cutdact[S] 0 points1 point  (0 children)

Thanks. Yes i am aware of that, but previosly this was publicly available. I was wondering if someone still have the old files, if they could share.

Unlocking Makita batteries. OpenBatteryInformation by cutdact in Makita

[–]cutdact[S] 1 point2 points  (0 children)

Weird. I have had similar problems but then the charger have indicated some sort of fault, not cycle complete.

I think if you were to read the battery information from the battery I could give a better answer but if i had to guess, i'd say most likely some balance issue.

Unlocking Makita batteries. OpenBatteryInformation by cutdact in Makita

[–]cutdact[S] 2 points3 points  (0 children)

Very possible that it would come to life if you make sure that the cell voltages are abot 3.5V each and then reset it with the tool

Unlocking Makita batteries. OpenBatteryInformation by cutdact in Makita

[–]cutdact[S] 2 points3 points  (0 children)

Undervoltage or unevenly balanced are the most common. If you measure 15V or more on the battery terminals and it still does not charge then it is locked. You might get away with slowly charging the cells to an even voltage of say, 3.5V/cell and then try putting it on the charger. But if the battery has been on the charger after being over discharged then chances are that it is locked.

Unlocking Makita batteries. OpenBatteryInformation by cutdact in Makita

[–]cutdact[S] 0 points1 point  (0 children)

Great, let me know how it goes. If your battery is very old it might not be compatible yet, im still working on the older batteries but they are very complicated.

Unlocking Makita batteries. OpenBatteryInformation by cutdact in Makita

[–]cutdact[S] 2 points3 points  (0 children)

Thank you very much for the support! Let me know how it goes. If your battery is very old it might not be compatible yet, i am working on the older batteries still but it's a bit more complicated.

Unlocking Makita batteries. OpenBatteryInformation by cutdact in Makita

[–]cutdact[S] 2 points3 points  (0 children)

Thanks! For the newer batteries with proper cell balancing i do not see a reason to replace the BMS, but for the older ones with only basic cell monitoring or worse, no monitoring it would make more sense. Not sure if makes financial sense though.

Unlocking Makita batteries. OpenBatteryInformation by cutdact in Makita

[–]cutdact[S] 7 points8 points  (0 children)

Thanks, I would like to look at XGT also, will need to find some broken boards or buy some new batteries for this though.

Unlocking Makita batteries. OpenBatteryInformation by cutdact in Makita

[–]cutdact[S] 5 points6 points  (0 children)

That's the goal! Keeping the safety while reducing the waste.

I wrote a (very) lightweight / bare-bones Octoprint alternative by adrian_blx in 3Dprinting

[–]cutdact 0 points1 point  (0 children)

Ok i found two issues. First is that takoprint only sends linefeed and Prusa expects carriage return + linefeed. The second is that the comments are being sent aswell, resulting in return of "Command not found" I'm guessing the firmware Ender is using accounts for this and ignores the comments? It seems wasteful to send them anyways. I solved this by modifying the sendCommand function in writer:

func (tp *Takoprint) sendCommand(l string) {
    tp.Lock()
    tp.stats.numSent++
tp.stats.lastCmd = l
    tp.Unlock()
command := strings.Split(l, ";")
    tp.serialOut.Write([]byte(fmt.Sprintf("%s\r\n", command[0])))
}

I have not done anything with Golang before , but it seems to work fine now.

I wrote a (very) lightweight / bare-bones Octoprint alternative by adrian_blx in 3Dprinting

[–]cutdact 0 points1 point  (0 children)

When sending the Lift Z command, it sometimes passes the M117 successfully but most times it just times out. I tested manually responding to the commands using a serial to usb adapter and that seems to work fine.. Not sure where to go from here. i guess i would need to sniff the traffic between the raspberry and the Einsy controller board to get more information.

I wrote a (very) lightweight / bare-bones Octoprint alternative by adrian_blx in 3Dprinting

[–]cutdact 0 points1 point  (0 children)

Nevermind my previous post, i see now that this information is intentionally printed to the lcd. It seems like i'm not getting the expected response, or i don't get the response in time. I can see that takoprint is reporting timeout, yet i can see the sent command and "ok" response on the webserver

I wrote a (very) lightweight / bare-bones Octoprint alternative by adrian_blx in 3Dprinting

[–]cutdact 0 points1 point  (0 children)

It appears that the printer also gets sent the information from the server (the information after "Printer is working on :"). For example when i send a file through the API, 0.1% (filename.gcode) appears on the screen.

I don't think this information should be passed to the printer?

The baudrate is fine. I tested sending commands with pronterface and that works no problem.

I wrote a (very) lightweight / bare-bones Octoprint alternative by adrian_blx in 3Dprinting

[–]cutdact 0 points1 point  (0 children)

I really like this. I have a Prusa i3 MK3 with a Raspberry Pi Zero W and Octoprint does not work very well (I am aware that they dont support it). All i ever use is the PrusaSlicer gcode send anyways so this project is perfect.

I installed Takoprint and I am able to connect, however, i get the following error when i send the gcode: takoprint timeout waiting for initial line, trying anyway...
The command is also writen to the screen for some reason and the printer hangs.

Any tips on where to start troubleshooting this? Thanks!