maikstohn / up3d Goto Github PK

I have conducted some system testing against the UPBox! (Rom V6.110 and Firmware V3.38)
The transcoder transcodes gcode to up code (.umc) with no problem.
The uploader uploads the .umc file, no problems apparent.
The UPBox! starts processing and regardless of current position moves the print head forward (towards the door in the Y axis) until it grinds (at which point I turn the printer off).

I started by testing with an UP Bunny sliced from Simplify3d
I then stripped the gcode down to just the first command (G90), same result.
I then stripped the input.gcode file to no commands (i.e. an empty file), same result.

I was able to use the "alternate UP software" control panel (in ModelWizard) to move the print head and bed, but I also got the message "Unsupported printer" when I tried to print from it.
My conclusion is the transcoding of gcode to UPCommands should be fine, but the .umc file header needs to be coded to specifically suit the UP printer model or something like that.

I saw you have added a new tool "upinfo.exe". I have executed it and output the results to a text file that I have attached to this issue.

I hope this helps?
If there is more information that you need or testing, please let me know.

Thanks
Adrian
upinfoOutput.txt

Hi Maik,
I think there is a bug in versions 4.1 and 4.2 of the transcoder when printing cylinders (or lots of angles)

I've been calibrating my printer with some custom thin wall models (just squares) I made up and everything has appeared to be fine.
I then upgraded from version 4.1 to 4.2. Assuming nothing related to transcoding had changed that would effect my calibrations, I started printing an S-plug. It printed the disk and disk with S hole perfectly, but the S on the top of the disk printed with a lean. See here for images =>

Thinking this might be a bug in 4.2, I downgraded to 4.1 and found the issue was still there and appeared across the entire print. This made me think maybe something was wrong with my hardware. So I printed it from the UP software and it came out perfectly, printed again from transcoder 4.2 and it leans again. See here =>

I then printed my boxes and squares again with version 4.2 and they came out fine, so I printed the s-plug again but nope still has a lean. see here =>

So at this point I "think" there is no issue with the hardware but with printing circles from the transcoder, so I crafted a basic cylinder to test with. Results can be seen here =>

A Cylinder printed with version 4.2 has a lean
A Cylinder printed with UP software is perfectly upright
A Cylinder printed with 3.0 is perfectly upright
The same g-code used again with version 4.2 again has a lean.

This zip contains my gcode, umc code and the STL I used.
Cylinder UMC GCODE and STL.zip

I am happy to be corrected and have it proven that my printer has a slip of some sort, but this looks like a bug in the latest transcoder versions to me (at least 4.1 and 4.2).
The other thought that has crossed my mind is maybe there is some "hack checking" going on from inside the UP firmware on the printer itself. I sure hope this is not the case....

Thanks
Adrian

It seems like there is no way to pull out or extrude filament in the tools here and I have no way to load/remove my filament when on my Linux machine. is there a way to get up3dshell to do these things or do I have to go on a windows and open up UP to do this?

Hi Maik,
I currently only have 1 printer, but now that we pretty much have this transcoder working, I am considering buying a second UPBox.
How does the upload.exe know which UP machine to send the umc file to?
I suspect this a setting that should be part of the upload.exe
Also which printer would the upshell read data from? I suspect this application would need a setting for it too.
I noticed the UP Software seems to differentiate between multiple printers by a serial number.
Normally with gcode printers they are differentiated by the COM port they are attached to.

Thanks
Adrian

Hi Maik,

Not sure if I should add this as an issue, but I don't see where else to write it.

Do you think we could wrap the up3dtranscode, upload and upshell applications up into a virtual USB/COM gcode port?
i.e. the idea being that Simplify3d (and others like Cura) could just communicate directly rather than dealing with gcode files and manually executing from the command line?
Would be great if the print progress and temperature values could be reported back into Simplify3d during printing.
Or maybe you've already though of this? I am guessing you probably have.

Thanks
Adrian

Archiv.zip

When loading two objects in Slic3r 1.2.9 the resulting umc file does not upload to the printer. It hangs right at the beginning of the transfer.

OS X 10.11.3

Batteriefach_123A_ABS_Komplett.txt

For users who want to put the tools somewhere in their PATH, it would be good, if some of the tools were renamed. Especially upload is pretty generic and could collide with other tools or custom scripts (for example I have a script named upload that uploads files to a public directory on my web server).

For consistency you might start all names with up3d or up3d- so upload might become up3dload, up3d-load, up3dupload, up3d-upload or something similar. I think I prefer the last one (which would make the other tools up3d-transcode and up3d-shell)

Hi,
I've just compiled up the convg tool and run it over the MemDump.dat file from FixUp3d.
The MemDump.dat was generated from a simple 10x20 cylinder print.
I then previewed the resulting gcode in Simplify3d. The preview shows the print head going all over the place.

I also ran the convg tool over the upcode generated file from up3dtranscode. Ie from gcode to upcode and back to gcode again.
The preview is even worse again.
Below is a preview of the source gcode

After transcoding and then converting back to gcode again it looks like this

I understand that the transcoder "mostly" works, so why can't we convert back and forth and get the same results?

Thanks
Adrian

looks like there were some firmware changes in the latest cetus 3D model.

./up3dload ../test.umc 
UPload: 1.07 kB sent (100%) [440.43 kB/sec]
ERROR: Write to SD not finished

I tried to comment out that check with the result of the printer slamming its bed against the upper limit.

Also I get some interesting output from up3dinfo

 ./up3dinfo 
UP 3D PRINTER INFO:
TypeID:2710 Serial:1 ROM:6.1400 Model:Please update your app U1:1.00 U3:1 U4:102 U7:100
Max-X:-180.000000 Max-Y:180.000000 Max-Z:185.000000 Steps/mm-X:160.000000 Steps/mm-Y:160.000000 Steps/mm-Z:160.000000 Steps--A: 10.000000 Print sets: 1
U2:0.00 U3:0.00 U10:0.00 U11:0.00 U12:0.00 U13:1.00
Set#0  Name:"Set 05"
  ND:0.00 LT:0.00 SW:0.00 ST:0.00 HW:0.00 HS:0.00 HL:0.00 XW:0.00 XS:0.00 XL:0.00 SV:0.00 
  HV:0.00 XV:0.00 JS:0.00 SZ:0.00 HZ:1.00 SZ:0.90 FZ:0.12 
  O1:20.00 O2:6.00 O3:1.00 O4:3000.00 O5:6000.00 O6:6000.00 U1:0.00 U2:0.00 U3:0.00 U4:0.00 U5:0.00 U6:0.00 

I'm willing to work on this but haven't quite figured out yet where to start.

Some more info:
I enabled _DEBUG_IN_OUT_
cetusCommLog.txt

the problem seems to be here:

>76 C6
<00 00 00 00 06

Hi, I have an Cetus3D prototype and it reports back a different PID.
System info tells me:

Cetus S7:
  Produkt-ID:   0x277f
  Hersteller-ID:    0x4745

So I modified up3dcomm.c to incorporate the new PID to see what it reports. Here is the result:

UP 3D PRINTER INFO:
TypeID:2710 Serial:1 ROM:6.1400 Model:Please update your app U1:1.00 U3:1 U4:102 U7:100
Max-X:-180.000000 Max-Y:180.000000 Max-Z:180.000000 Steps/mm-X:160.000000 Steps/mm-Y:160.000000 Steps/mm-Z:160.000000 Steps--A: 10.000000 Print sets: 1
U2:0.00 U3:0.00 U10:0.00 U11:0.00 U12:0.00 U13:1.00
Set#0  Name:"Set 05"
  ND:0.30 LT:0.05 SW:0.25 ST:1.00 HW:0.25 HS:4.00 HL:3.00 XW:0.28 XS:6.00 XL:3.00 SV:20.00 
  HV:25.00 XV:25.00 JS:180.00 SZ:1.00 HZ:1.00 SZ:0.90 FZ:0.12 
  O1:20.00 O2:6.00 O3:1.00 O4:1000.00 O5:1500.00 O6:1500.00 U1:0.00 U2:0.00 U3:0.00 U4:0.00 U5:0.00 U6:0.00 

Not sure what all the information should tell me, but I like to build support for this this printer into the transcoder.

Update: I extended the the setting in up3dtranscode for the Cetus. Mainly I copied the mini settings and changed the resolution to 160 steps/mm for yxz. Running the transcoder and uploading it to the Cetus works. Printing starts work, but I get some way to high speed during infill,e.g. it seems at least a factor 3 too high. Brim, first Layer, Perimeters and top layer are OK. Only the wired infill speed.

I use the newest Slic3r 1.2.9 on OS-X. Transcoding for the UP! Mini works without this speedy infill.

I got a weird issue, but first things first:

UP!Mini, purchased at Tchibo in February
UP-Software 2.18
ROM V6.110
FW V3.34
Slicer: Simplify3D
Using newest up3dtranscode.exe, upshell.exe and upload.exe

Every time i transcode and upload a file with a size over 30 MB (did'nt test between 20 and 30 MB), the upload results either in a SD Card Failure or it uploads, starts printing and the nozzle runs into the clips at the side of the build platform (see attachments). Nearly got a heart attack hearing the sound it makes ^^

Tried it with the Predator Bust HD (failes), TIE Fighter (failes) but e. g. the Buddha works from thingiverse. The file size of the Buddha.gcode/umc is 15.868 KB/15.014 KB. Predator is 47.265 KB/49.104. On the other hand, the TIE file is 6.139 KB/10.177 KB and produces the same error. So it is maybe not the file size.

While uploading the %-Scale jumps from 49% to -50% to 7%.

c:\UP3DTOOLS>up3dtranscode predator4.gcode predator.umc 121.39
Height: 112.37mm / Layer: 560 / Time: 13h:30m:43s
Nozzle Height: 121.39mm

c:\UP3DTOOLS>upload predator.umc
UPload: 49103.91 kB sent (14%) [114.45 kB/sec]]UPload: 35229.38 kB sent (-13%) [117.80 kB/sec]
ERROR: Write to SD not finished

So i transcoded and uploaded again:
c:\UP3DTOOLS>upload predator4.umc
UPload: 49049.10 kB sent (14%) [118.67 kB/sec]]UPload: 48885.47 kB sent (14%) [118.72 kB/sec]

Other files i transcoded and uploaded are working flawless. Great tool btw :)

So is it an error while uploading, in the stl itself (UP Software prints it normal), transcode or me?

Hi,thanks for all this work.

But I did not get it to work. On 64 bit Windows 10 I get the error it's not compatible (32 bit).

Then I tried 32 bit Win XP but I getan error trying to ranscode: something with 16 bit DOS invalid instruction...

Can somebody with Windows help or will this be fixed with the new GUI?

Hi,
I get this weird behavior on my UP2 Plus 3DP.
I tried to 3D Print the "Marvin_KeyChain" model, both with Cura and Simplify3D, Change parameters etc but with both of them I got this behavior:


It's need to be like this:

on the UP Software, the print go out well as usual.

UP Plus2(H)
ROM: V6.090
Firmware: V3.07
Windows10, 64Bit, Hebrew

All file (STL, GCODE, Settings etc.) is here:
Debug 11-04-2016.zip

For printer firmware <330 the program generates a segmentation fault. The issue seems might be caused of a additional pointer increment in up3dc.c:

    {
      uint8_t UP3D_CMD_2F_X[] = { 0x2F, b };
      memcpy( &send[0], UP3D_CMD_2F_X, 2 );
      memcpy( &send[2], data, 20*b );
  **    data++; //  should be removed **
      if( UP3DCOMM_Write( send, 2+20*b ) != 2+20*b )
        return false;
      blocks -= b;
      data += b;
    }

EDGE_HA_wingR_5.gcode.zip
Hello! I am having problems setting the nozzle of my upbox to the right height from the bed. When the uploader send the transcoded GCODE, the nozzle starts printing very, very far from the bed, like 10 cm away or more! In my upbox studio, the nozzle height configured that I always use for best printing is 210.3 (latest MACOSX version of up studio). I am passing this value to the transcoder (the last argument of the transcoder command: 210.3).
I am also using the latest transcoder/uploader available to download (for MACOS).
I am using the latest version of Slic3r to generate the GCODE. In slic3r I set for the bed x: 250; y: 200 and z offset as 0. The firmware I am using is the default suggested (RepRap/Marlin..)
Please note that I am not using z offsets anywhere, so, I am very confused of what is going on..

The gcode generated in slic3r is in the zip file attached.

Anyone has idea of what is going on???
Thanks a lot!

After transcode and uploading the printed object is flipped on either x or y axis.

Hi Maik,

Now that I can use other slic3rs..Are there a maximum temperatures I should keep under for the extruder and the bed (specifically on my UP Box)?

Thanks
Adrian

Hi everyone listening to this project,

summer starts to be over here in central Europe, so there is more time spending at the printer again.
I wanted to share some recent findings during working on supporting the Cetus3D printer with this project.

When printing from G-Code generated by Simplify3D I noticed that there is a partial shift of the infill, half of the infill bonds fine to the perimeter. The shift I noticed is not a complete infill shift, it affects only 2 sides.

The strange thing is that printing the same object via UP Studio or with Slic3r generated G-Code there is no shift. See the picture of the 3 versions top layer for comparison.

Then drilled deeper into the issue by looking at the generated G-Code by this chain:
Simplify3D -> up3dtranscode -> parse back to g-code.
There I could not see any issues.

Next I wrote a little command line tool to live capture the position information from the printer (like the data that up3dshell reports) with a high data rate of ca. 500 samples/sec (1000 samples/sec was also possible, but there were more hick-ups). Next I translated the capture stream back to G-code for visualization (the result still needs more post processing, so you won't be able to print it).

Visualizing the captured top layer movement data inside Simplify3D G-Code viewer shows clearly the same infill shift problem then the printed part! So at least I got the capture part working for this visualization (ignore the red lines sticking to the part, these are the hick-ups on getting data from the printer). I also looked on all the other layers. This shifting is in all layers present.

The Cetus3D printer has only 160 steps/mm on x/y compared to the other models > 800 steps/mm. So any processing quirks are more visible (factor of 5) with this printer. So we still might have transcoder related issues (precession/rounding or firmware limitation of the command parameters). When I have more time I might do the same exercise with my Up mini to compare...

Overview of the 3 versions printed:

Detailed view of the Simplified3D Version:

Simplify3D -> transcode -> parse -> g-code view in Simplify3D:

Captured data from the printer (Cetus3D) and translated to g-code for viewing:

capture with different translation processing (more raw data like):

Original STL:
Cube20x20x10_with_hole10.stl.zip

Sliced G-Code from Simplify3D:
Cube20x20x10_with_hole10.gcode.zip

captured position data:
Cube20x20x10_with_hole10.Cetus.capture.zip

Back translated captured print data:
Cube20x20x10_with_hole10.Cetus.capture.gcode.zip

Hi,
It appears the convg tool does not differentiate between print and travel moves.
I have converted a gcode file from Simplify3d to upcode and then back to gcode and the Simplify3d previewer shows the travel only lines in with the normal print lines (i.e. even when I uncheck the "Travel moves" check box). It does not do this on the original gcode file though.

I am hoping this is an insignificant bug in the convg tool and not a bug in the transcoder?

Thanks
Adrian

Please note that new updates are currently available here:

https://github.com/UP3D-gcode/UP3D/releases

When uploading my cube.umc (111kb) file from OSX right after turning to the UPMini it gets stuck at 30%. The power led is purple (alternating between red and blue very fast).

./upload cube.umc
UPload: 32.34 kB sent (30%) [11.87 kB/sec]

Any clues?

Hi @MaikStohn , @kscheff ,
I'm not sure if this is an issue or not. It is possible I just need to learn how to calibrate retraction settings for my printer.

But, with a standard preview from Simplify3d I can see a retraction point at this junction.

Of course, gcode does not show accelerations or decelerations, so I wont bother adding a screenshot with the retraction removed.
But after converting to up code and then back to gcode (and removing the retraction point) I can see the deceleration (and acceleration).

In my real print, this is resulting in a disconnected tube (i.e. a C tube instead of an O tube).

The gap shown here is tough to get in a photo, but it runs the entire length of the print.

Is this an issue? Or is it just some retraction calibration settings I should amend?
If it's just retraction settings can you advise on a good technique to calibrate these?

Thanks
Adrian

Hi @MaikStohn, @kscheff,
Testing version "UP3DTOOLS_WIN_20160508_v0.6.2" with my UPBox, there is an issue with the layer positioning.
The error can be seen both in a real print and when converting back to gcode.
This is the original preview

After converting to up code and then back to gcode, the preview looks like this

I considered this may just be an issue with the preview only from converting back and forth so I printed it anyway, but the real print has the layers off too.

Adrian

The files might help :), I couldn't zip everything so I excluded the upcode and the converted back to gcode files (as I figured you could reproduce them with your tools anyway)
LayerPositioningIssue.zip

Hi,
Not sure if it's just me but I get this error when trying to run the transcoder.

Hi, I have problems cross-compiling the up3dwifisrv with osx, can you update the ipk? my printer works, but, shows as "TEST2" name and aways give a connection error at first....

Thanks

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

New UP studio can set a custom name for every printer (most likely stored in a SD block).

We need to implement read/write for this (very useful for WiFi printer connection)

I know it's not strictly the focus of this project but it would be nice to have some documentation about which settings to use when generating gcode for the different Up printers. As far as I'm aware there's no official documentation of the printers' max speed, max acceleration, etc. and I assume most users that use the code from this repository (such as myself) are used to the Up3D software and rather inexperienced with Simplify3D, Slic3r, etc...

Thanks for your great effort!

I was wondering: When creating GCODE from Cura, does it matter for which printer is selected? And therefore which GCODE flavour is used?

When I select Ultimaker 2go in Cura up3dtranscode shows this error when executed: GCP ERROR at line 11: UNSUPPORTED command >>G10. So added a 'Prusa i3' in Cura. Now the output.umc file is succesfully created.

What printer / slicer settings should I use in Cura?

I fixed the source to connect to 277D pid and not 2777 pid as originally set in code (for up2plus) and when I try to up3dload it freezes after 28.13kb

H:\toolpaths>dir
 Volume in drive H is DATA1
 Volume Serial Number is 2CFC-484F

 Directory of H:\toolpaths

09/25/2016  01:45 AM    <DIR>          .
09/25/2016  01:45 AM    <DIR>          ..
09/25/2016  01:42 AM         2,448,813 melzi_highrise2.gcode
09/25/2016  01:45 AM         7,257,060 melzi_highrise2.umc
               2 File(s)      9,705,873 bytes
               2 Dir(s)  323,968,217,088 bytes free

H:\toolpaths>"e:\bin\UP3DTOOLS\up3dload - 7D.exe" melzi_highrise2.umc
^Cload: 28.13 kB sent (0%) [17.59 kB/sec]
H:\toolpaths>"e:\bin\UP3DTOOLS\up3dload - 7D.exe" melzi_highrise2.umc
UPload: 28.13 kB sent (0%) [17.96 kB/sec]

problematic files attached

toolpaths.zip

I can send commands through the UP slicer but cannot get it to respond in the command line. I have an UP mini.

Didn't know where else to post it, hoped from here it would be useful.

My UP CPU V5 hasn't been properly scratched out and I can make out some of the text.

980 TF
TNP 12??
E5P Y9W
58?D8W
??

Might help someone Question marks are where I know there is a number or letter but haven't a clue what they are.

Does this tool work on the new UpBox+ . I think the machine ID is 2782

How do I make it work for this printer?

When I run it it comes up with ""[ERROR] USB Open Device (0001:2777/277D/277F/0001) not found" or something like that.

I got that number (2782)from the device manager properties for the usb device hardware id.

Regards Dennis

I have been looking for the extruder calculations and this confuses me. In the up3dconf.c file is the definition like this:

settings_t settings_mini = { 
  .steps_per_mm = { 854.0, 854.0, 854.0 },
  .max_rate = { 200, 200, 50 },
  .acceleration = { 1500, 1500, 300 },
  .junction_deviation = 0.05,
  .x_axes =  1, .y_axes =  0,
  .x_dir  =  1, .y_dir  = -1, .z_dir  = -1,
  .x_hspeed_hi = 50.0, .y_hspeed_hi = 50.0, .z_hspeed_hi = 50.0, .x_hofs_hi =  4.0, .y_hofs_hi =  4.0, .z_hofs_hi =  6.0,
  .x_hspeed_lo = 10.0, .y_hspeed_lo = 10.0, .z_hspeed_lo =  3.0, .x_hofs_lo =  9.0, .y_hofs_lo =  2.0, .z_hofs_lo =  2.0,
  .heatbed_wait_factor = 20.0,
};

So for the UP mini we have 854.0 steps per mm for XYZ axis. There is no definition for the extrude axis. Looking inside the hoststepper.c I see the following:

  //calc time based on corrected steps
  double tx = fabs(s_x / (512*settings.steps_per_mm[0]) / v);
  double ty = fabs(s_y / (512*settings.steps_per_mm[1]) / v);
  double ta = fabs(s_a / (512*settings.steps_per_mm[2]) / v);

The parameter .steps_per_mm[2] refers to the Z axis steps per mm, but it is used to calculate ta (which is for the extruder I guess).

It might be that on the UP mini and others the Z and A axis have the same steps_per_mm amount, but this might not be the cases on "newer" models.

Was testing out the new release v0.7.0 and it is printing at a slight angle 3-5 degrees. Raft was solid and I don't get this issue through the UP! Software.

gcode and umc file are in the zip tensile-specimen.zip

Hi,
I have some problem to change the firmware on the TP-Link WR703N 3.17.1 Build 140120 Rel.56593n router to OpenWRT, I tried all trick that I can get but nothing work.
the default password is adminadmin (2x admin) and I can't use any hack include this:
https://connectbox.technology/wp/2016/03/16/hack-the-wr703n-version-1-7-to-put-on-whatever-openwrt-firmware-variant-you-want/
but it's not work.
how did you make it work?

Yaniv G
[email protected]

After gerenrating a gcode file with Slic3r (Temperature of Extruder set to 228° and Bed to 90°) I checked the file and found M104 S228 command lines in the gcode file.
Transcoding works fine, uploading works fine, after a few seconds the printer initializes and starts to move.
The temperature of the nozzle stays calm.
Any ideas?

Thanky in advance...

Thanks to some nice Tiertime developer we now have some header files with several definitions.

The new MacOS version (only available on MacOS-X App Store) does have several header files included. Folder: /Applications/UpStudio.localized/UpStudio.app/Contents/Resources/inc

2DModel.h
3DModel.h
3dmath.h
CFile.h
GElement.h
ListArray.h
PrintLink.h
Slicer.h
TTPrint.h
TT_define.h
WinTypedef.h
printparam.h

Very promising :-)

New UP Studio finally implemented the job control + reprint.

We need to analyze and implement this feature. It is just saving/reading some extra data for every print from SD card.

Hi Maik,
It appears the "UP3DTOOLS_WIN_20160426_v0.4.0" transcoder is broken. It just hangs. Previous version still runs though so its not something local.

Adrian

I compiled the up3dwifisrv under OS X and run it in foreground to see debug output.
When connecting from a windows machine (Settings/Printer) running Up Studio I get the following output:

Received UDP packet from 192.168.0.15:54834
Search UP...
Received UDP packet from 192.168.0.15:54834
Search UP...
Received UDP packet from 192.168.0.15:54834
Search UP...
Received UDP packet from 192.168.0.15:54834
Search UP...
Received UDP packet from 192.168.0.15:54833
Connect UP...

Running the same procedure from OS X Version of Up Studio I the final Connect UP... message is missing.

I cannot verify further the Windows version of UP Studio, since it doesn't run well under VirtualBox.

I wonder if there is any way to support the Mini 2?
The USB vendor:device ID is 0x4745:0x2780, I managed to tweak and compile up3dcomm.c to try that device ID but up3dinfo gives me a partially valid output:

UP 3D PRINTER INFO:
TypeID:2710 Serial:1 ROM:6.1300 Model:Please update your app U1:1.00 U3:1 U4:102 U7:100
Max-X:-120.000000 Max-Y:120.000000 Max-Z:130.000000 Steps/mm-X:214.000000 Steps/mm-Y:214.000000 Steps/mm-Z:214.000000 Steps--A: 10.000000 Print sets: 1
U2:0.00 U3:0.00 U10:0.00 U11:0.00 U12:0.00 U13:1.00
Set#0 Name:"Set 0"
ND:0.00 LT:0.00 SW:0.00 ST:0.00 HW:0.00 HS:0.00 HL:0.00 XW:0.00 XS:0.00 XL:0.00 SV:0.00
HV:0.00 XV:0.00 JS:0.00 SZ:0.00 HZ:1.05 SZ:0.90 FZ:0.60
O1:20.00 O2:6.00 O3:1.00 O4:1500.00 O5:3000.00 O6:3000.00 U1:0.00 U2:0.00 U3:0.00 U4:0.00 U5:0.00 U6:0.00

Regards,
Alex

I wanted to learn how to communicate with USB devices.
I felt re-implementing this library would be a good exercise.

I've got communications with the device and can successfully query the firmware version.

But there isn't much explanation on how this protocol works.
Like I see many lines of code like this one:

Does the number six represent success?
Is there documentation on this protocol or did you just reverse engineer the protocol for these printers?
If yes, what tools/processes did you use to reverse engineer the protocol?

I'm currently investigating a problem where my UP!Mini stops after having printed some layers. In my second attempt it stopped at the same place with the same UMC file. I'm trying with another UMC file now.

This was the state in UP!3D Shell when it stopped.

                                                     UP!3D SHELL

Machine-State: (2) Running Program     Program-State: (0) Program Stop      System-State: (01) System Ready


Motor 1: State: (0) STOP      | Limit+: (00000000) | Limit-: (00000000) | Axis X State: (0) No Error    Pos: -52948
Motor 2: State: (0) STOP      | Limit+: (00000000) | Limit-: (00000000) | Axis Y State: (0) No Error    Pos: 56364
Motor 3: State: (0) STOP      | Limit+: (00000000) | Limit-: (00000000) | Axis Z State: (0) No Error    Pos: -105896
Motor 4: State: (0) STOP      | Limit+: (00000002) | Limit-: (00000000) | Axis A State: (0) No Error    Pos: 181040


Print-State: Not Printing Layer: 1    Height: 2.470 Progress:  30%                            Time Remaining:  0:17:46


Heater 1: ActualTemp: 240.2 C TargetTemp: 240.0 C SetTemp: 240.0 C Temp Reached: YES Hea *** HF 1: 0
Heater 2: ActualTemp: 248.1 C TargetTemp: 230.0 C SetTemp:   0.0 C Temp Reached: YES Hea *** HF 2: 0
Heater 3: ActualTemp:  51.4 C TargetTemp:  50.0 C SetTemp:  50.0 C                   Hea *** HF 3: 0
Heater 4: ActualTemp: 113.1 C TargetTemp: 105.0 C SetTemp:   0.0 C                       *** HF 4: 32


Have Support: No  Feed Error Length: 2000 Feed Back Length:   0.000 Change Nozzle Time:   0.000 Jump Time:   0.000 Usi


Check Door:    1 Check 24V:    0 Check PowerKey:    1 Check LightKey:    1 Check WorkRoomFan:    0


Read From SD Card: 0 Write To SD Card: 0 PausePRG: 0 StopPRG: 0 InitPRG: 0 ISTATE: 0


3D:00000000 3E:00000130 3F:00000000 40:00000008 41:000000f0 42:00000000 43:00000032 44:00000000 45:00000000 46:0000000
48:00000000 49:00000050 4A:00000000 4B:00000000 4C:0000001e 4D:0000043c 4E:00000000 4F:00000000 50:00000000 51:0000000
54:00000000 55:00000000 56:00000000 57:00000000 58:00000000 59:00000000 5A:00000000 5B:00000000 5C:00000000 5D:0000000
60:00000000 61:00000000 62:00000000 63:00000000 64:00000000 65:00000000 66:00000000 67:00000000 68:00000000 69:0000000
6C:00000000 6D:00000000 6E:00000000 6F:00000000 70:00000000 71:00000000 72:00000000 73:00000000 74:00000000 75:0000000
78:00000000 79:00000000 7A:00000000 7B:00000000 7C:00000000 7D:00000000 7E:00000000 7F:00000000 80:00000000 81:0002c35
84:bc03147b 85:3ed84091 86:00000000 87:00000000 88:43d48000 89:449b0000 8A:00000000 8B:00000000 8C:00000001 8D:0000000
90:00000000 91:00000000 92:00000000 93:00000002 94:00000000 95:00000001 96:00000000 97:3eb851ec 98:3eb851ec 99:3d75c28
9C:c1200000 9D:c1200000 9E:c1200000 9F:00000000 A0:00000000 A1:00000000 A2:00000000 A3:00000000 A4:00000000 A5:0000000
A8:00000000 A9:00000000 AA:00000000 AB:00000000 AC:00000000 AD:00000000 AE:00000000 AF:00000000 B0:00000000 B1:0000000
B4:00000000 B5:00000000 B6:00000000 B7:00000000 B8:00000000 B9:00000000 BA:00000000 BB:00000000 BC:00000000 BD:0000000
C0:00000000 C1:00000000 C2:00000000 C3:00000000 C4:00000000 C5:00017fca C6:00017f62 C7:00000003 C8:00000000 C9:0000000
CC:00000000 CD:00000000 CE:00000000 CF:00000000 D0:00000000 D1:00000000 D2:00000000 D3:00000000 D4:00000000 D5:0000000
D8:00000000 D9:00000000 DA:00000000 DB:00000000 DC:00000000 DD:00000000 DE:00000000 DF:00000000 E0:00000000 E1:0000000
E4:00000000 E5:00000000 E6:00000000 E7:00000000 E8:00000000 E9:00000000 EA:00000000 EB:00000000 EC:00000000 ED:0000000
F0:00000000 F1:00000000 F2:00000000 F3:00000000 F4:00000000 F5:00000000 F6:00000000 F7:00000000 F8:00000000 F9:0000000
FC:00000000 FD:00000014 FE:00000010 FF:00000010
84:-0.008000 85:0.422368 86:0.000000 87:0.000000 88:425.000000 89:1240.000000 0
97:0.360000 98:0.360000 99:0.060000 9A:0.360000 9B:-10.000000 9C:-10.000000 9D:-10.000000 9E:-10.000000