-
Notifications
You must be signed in to change notification settings - Fork 32
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Error while sending umc code file #6
Comments
Hi, From the screen shot I can see that you use a unicode folder name in your path which already got corrupted when looking at it in the CMD window. Maybe this also cause problems to the upload program. In case you want to use the transcode for UP2 Plus you also have to find out / experiment if all the steps/mm, speed and other parameter (in "up3dconf.h") match your printer and recompile it after making changes. |
Hi, so it looks like something is handled different on UP2 Plus. Unfortunately I don't have this kind of printer and would rely on somebody to debug / test the problem. A simple test would be to activate the usb debug in source code and provide the output of it. In "up3dcomm.h" you can see a line: //#define DEBUG_IN_OUT remove the // at the begin of the line and recompile to activate the output. |
How can I compile the code? I only run the exe files. |
I compiled it for you. Please find the extra "upload_dbg.exe" in the release folder. You can redirect the debug output to a file for easy transfer by using following command line: upload_dbg.exe mymodel.umc >upplus2dbg.txt 2>&1 |
upplus2dbg.txt |
Hi, Basic communication is working, but it looks like the USB transmission is getting an error. I will have to add some more debug output around this stuff to get a better idea what happens (I will do this within the next days and upload a new version for you) |
I have someone with a similar bug write to SD Card failed. It is an Up mini from the first Tchibo batch, same as mine (and mine works). I traced the issue down to a failing USB bulk transfer. The stack returns -7 (timeout) on the first try to send data after selecting the SD Program 5. I tried to modify the program numbers to 1,4,6 ... no change in behavior. The platform is OS X for this experiment. Update: Same behavior with the printer when running under OS X Parallels/Windows XP SP3 using the Windows binaries to upload. The same umc file works on my printer fine.
|
Good test. Thanks for ruling out the program number. I have 2 ideas what could be changed to make it working: Increase the 500ms timeout to 5000ms for testing (last parameter of libusb_bulk_transfer) In file "up3d.c" in function "UP3D_WriteBlocks" change the max block value from "72" to "3": |
So a block size of 3 is doing the job 🎱 The about box of the Up 2.17 software for the non-working printer says: My working printer has a more recent version: I modified it in the upload.c file and made it available via command line upload.c
|
Great finding. USB CMD 00 returns the firmware version and is used at printer detection already. |
This is already incorporated, please see pull request.
|
I added a 3 block max workaround for older firmware versions and updated the binaries in the release folder. The "upload to sd failed" should be solved by this. |
It is confirmed to work now. |
Hi,
UP2 Plus, Win10 64 bit, Hebrew.
Using Cura 15.04.2.
I got this message when sending file to the printer:
"ERROR: Write to SD failed"
all files is here: (Cura Settings, Screenshot etc.)
https://drive.google.com/folderview?id=0Bzu7kkgSCcGgX2oxajU5MUNiYlk&usp=sharing
The text was updated successfully, but these errors were encountered: