Closed yanivg101 closed 8 years ago
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 I got the same error as yanivg101. I didn't use a unicode path. My printer is UP plus
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_INOUT
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. Can you make special exe file with the flag?
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 I tried to run the debug version, here is te output. Please comment ;)
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.
int UP3DCOMM_Write( const uint8_t *data, const size_t datalen )
{
#ifdef _DEBUG_IN_OUT_
fprintf(stderr,">"); _print_buffer( data, datalen );
#endif
int written;
int ret;
ret = libusb_bulk_transfer( _libusb_dev_handle, (EP_OUT | LIBUSB_ENDPOINT_OUT), (uint8_t*)data, datalen, &written, 500);
if (ret != 0)
{
#ifdef _DEBUG_IN_OUT_
fprintf(stderr,"UP3DCOMM_Write failed with error code %d. Bytes %d of %d written", ret, written, (int)datalen );
#endif
return -1;
}
return written;
}
Good test. Thanks for ruling out the program number.
I have 2 ideas what could be changed to make it working:
1) Increase the 500ms timeout to 5000ms for testing (last parameter of libusb_bulk_transfer)
2)
In file "up3d.c" in function "UP3D_WriteBlocks" change the max block value from "72" to "3":
if( b>72 ) b = 72; ==> if( b>3 ) b = 3;
This will reduce the max (logical) USB transfer size from 2048 byte down to 64 byte per block. I saw this in some older UP software. Maybe the firmware in the UP MCU is a bit older and requires this. It might be possible that the UP software chooses max packet size based on firmware version.
So a block size of 3 is doing the job :8ball: Increasing the time out to 5000 for USB did not work. Any value above 3 does not work for this printer.
The about box of the Up 2.17 software for the non-working printer says: Rom: V6.060 Firmware: V3.06
My working printer has a more recent version: Rom: V6.110 Firmware: V3.33
I modified it in the upload.c file and made it available via command line
upload.c
int block_size = 72; // default number of blocks for USB transfer to SD Card
if (argc == 4)
if (strcmp(argv[2], "-b") == 0)
if (sscanf(argv[3],"%d", &block_size) == 1)
argc = 2;
for(;;)
{
UP3D_BLK blocks[block_size];
int nblocks = fread( blocks, sizeof(UP3D_BLK), block_size, flat );
if( nblocks<=0 )
break;
Great finding.
USB CMD 00 returns the firmware version and is used at printer detection already. I will add an automatic limiter for smaller firmware versions.
This is already incorporated, please see pull request. It automatically reduced the block size to 3 in case firmware reports < 330.
Am 08.04.2016 um 21:26 schrieb Maik Stohn notifications@github.com:
Great finding.
USB CMD 00 returns the firmware version and is used at printer detection already. I will add an automatic limiter for smaller firmware versions.
— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/MaikStohn/UP3D/issues/6#issuecomment-207568819
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