Display Calibration Info in UI

[jmkao]

External slicers need to be supplied with the physical dimensions/resolution of the printer, which we can now easily determine via the calibration function.

To get this into slicers, it would be helpful to display this information, rather than going manually into the slicing profile and calculating it out of the XML. Looking across different slicers, it seems like the following representations would handle what most systems input:

• X pixels (e.g. from X windows)
• Y pixels (e.g. from X windows)
• X physical dimension (X pixels / DotsPermmX)
• Y physical dimension (Y pixels / DotsPermmY)
• Diagonal physical dimension (sqrt(Xdim^2 + Ydim^2))
  • SLAcer.js uses this
• X Pixels per mm (DotsPermmY)
• Y Pixels per mm (DotsPermmY)

A JSON API to retrieve this would also help me use a tool to query the server and build Autodesk Spark machine profiles.

[WesGilster]

I think I've posted this somewhere on some issue:
http://localhost:9091/services/printers/get/[Your printer name]

I'll make a deal with you, if you want to swaggerize our build, I'll add all of the annotations to the code and we'll have a pretty awesome fully documented API. I've been a bit reluctant to do this, but now that they are an open standard I'm not so worried about adding "proprietary" annotations to the code. I'm not promising a stable API just yet though. There are some funky things that don't "look" right, and those things are certainly going to change...

{  
   "configuration":{  
      "name":"mUVe 1",
      "machineConfig":{  
         "name":null,
         "FileVersion":0,
         "PlatformXSize":134.0,
         "PlatformYSize":75.0,
         "PlatformZSize":185.0,
         "MaxXFeedRate":0,
         "MaxYFeedRate":0,
         "MaxZFeedRate":0,
         "XRenderSize":1824,
         "YRenderSize":984,
         "MotorsDriverConfig":{  
            "DriverType":"eGENERIC",
            "ComPortSettings":{  
               "PortName":"Autodetect 3d printer firmware",
               "Speed":115200,
               "Databits":8,
               "Parity":"None",
               "Stopbits":"One",
               "Handshake":"None"
            }
         },
         "MonitorDriverConfig":{  
            "DLP_X_Res":1824.0,
            "DLP_Y_Res":984.0,
            "OSMonitorID":"Simulated display",
            "DisplayCommEnabled":false,
            "ComPortSettings":{  
               "PortName":"Autodetect projector",
               "Handshake":"None"
            },
            "MonitorTop":0,
            "MonitorLeft":0,
            "MonitorRight":0,
            "MonitorBottom":0,
            "UseMask":false
         }
      },
      "slicingProfile":{  
         "gCodeHeader":"G21 ;Set units to be mm\nG91 ;Relative Positioning\nG28 ; Home Printer\nM650 D${ZLiftDist} S${ZLiftRate} P0; CWH Template Preferences\nM17 ;Enable motors",
         "gCodeFooter":"M18 ;Disable Motors",
         "gCodePreslice":null,
         "gCodeLift":"M651; Do CWH Template Peel Move\nG1 Z${((LayerThickness) * ZDir)}",
         "gCodeShutter":null,
         "name":null,
         "selectedInkConfigIndex":0,
         "zliftDistanceGCode":"M650 D${ZLiftDist} S${ZLiftRate}",
         "zliftSpeedGCode":"M650 D${ZLiftDist} S${ZLiftRate}",
         "DotsPermmX":13.611940298507463,
         "DotsPermmY":13.12,
         "XResolution":1824,
         "YResolution":984,
         "BlankTime":0,
         "PlatformTemp":0,
         "ExportSVG":0,
         "Export":false,
         "ExportPNG":false,
         "Direction":"Bottom_Up",
         "LiftDistance":5.0,
         "SlideTiltValue":0,
         "AntiAliasing":false,
         "UseMainLiftGCode":false,
         "AntiAliasingValue":0.0,
         "LiftFeedRate":50.0,
         "LiftRetractRate":0.0,
         "FlipX":false,
         "FlipY":true,
         "ZLiftDistanceCalculator":"var value = 9.0;\nif ($CURSLICE > $NumFirstLayers) {\n value = 3.5555555555555420e+000 * Math.pow($buildAreaMM,0) + 4.3333333333334060e-003 * Math.pow($buildAreaMM,1) + 1.1111111111110492e-006 * Math.pow($buildAreaMM,2);\n}\nvalue",
         "ZLiftSpeedCalculator":"var value = 0.25;\nif ($CURSLICE > $NumFirstLayers) {\n value = 4.6666666666666705e+000 * Math.pow($buildAreaMM,0) + -7.0000000000000184e-003 * Math.pow($buildAreaMM,1) + 3.3333333333333490e-006 * Math.pow($buildAreaMM,2);\n}\nvalue",
         "ProjectorGradientCalculator":"var bulbCenter = new Packages.java.awt.geom.Point2D.Double($buildPlatformXPixels / 2, $buildPlatformYPixels / 2);\nvar bulbFocus = new Packages.java.awt.geom.Point2D.Double($buildPlatformXPixels / 2, $buildPlatformYPixels / 2);\nvar totalSizeOfGradient = $buildPlatformXPixels > $buildPlatformYPixels?$buildPlatformXPixels:$buildPlatformYPixels;\nvar fractions = [0.0, 1.0];\n//Let's start with 20% opaque in the center of the projector bulb\nvar colors = [new Packages.java.awt.Color(0.0, 0.0, 0.0, 0.2), new Packages.java.awt.Color(0.0, 0.0, 0.0, 0.0)];\nnew Packages.java.awt.RadialGradientPaint(\n\tbulbCenter,\n\ttotalSizeOfGradient,\n\tbulbFocus,\n\tfractions,\n\tcolors,\n\tjava.awt.MultipleGradientPaint.CycleMethod.NO_CYCLE)",
         "ExposureTimeCalculator":"var value = $FirstLayerTime;\nif ($CURSLICE > $NumFirstLayers) {\n\tvalue = $LayerTime\n}\nvalue",
         "SelectedInk":"Default",
         "MinTestExposure":0,
         "TestExposureStep":0,
         "InkConfig":[  
            {  
               "PercentageOfPrintMaterialConsideredEmpty":10.0,
               "Name":"Default",
               "SliceHeight":0.1,
               "LayerTime":8000,
               "FirstLayerTime":20000,
               "NumberofBottomLayers":10,
               "ResinPriceL":65.0
            }
         ]
      },
      "MachineConfigurationName":"mUVe 1",
      "SlicingProfileName":"mUVe 1",
      "AutoStart":false,
      "Calibrated":false
   },
   "started":false,
   "shutterOpen":false,
   "displayDeviceID":null,
   "currentSlicePauseTime":0,
   "status":"Ready",
   "printInProgress":false,
   "cachedBulbHours":null,
   "printPaused":false
}

[jmkao]

It's a deal, I need to learn swagger for work anyway, might as well start here :)

[WesGilster]

I assume we are done with this issue, but I'm taking it over to ask a quick question about calibration. Any quick requests about calibration? I printed something recently before I realized that I didn't have my printer calibrated properly. I figure what I've done is already good enough, but I thought I remember James wanting some calibration where you move the crosshairs to the extent of the screen and give an mm measurement of the screen width, length. This would be more accurate calibration, but I wasn't sure if there was anything else that I was missing.

[jmkao]

Oh, I think I was positing a second calibration to set the printable region within the projection area, for printers that cut off the edges of projection. I don't think we need to implement that until someone asks for it.

[jmkao]

Also, for this issue, let me assign that to myself. I want to implement a simpler interface for slicers to get calibration info rather than parsing the whole printer config.

[WesGilster]

Before you implement too many functions that return varying subsets of objects from the server interface, you may want to do a quick test to determine how much you are going to really trim from the performance. We are currently downloading the entire set of printers(in my case 3) and each of their entire object graph configurations in 18ms. That's hard to optimize. Parsing that json is a browser based CPU task that will take a fraction of that time. Forcing the browser to update the DOM will probably be the highest cost, but DOM updates are generally fixed costs unrelated to the size of http payloads. The key to optimizing Angular is keeping down the total count of watched variables, because that is what generally causes the most DOM updates. This is part of the reason that the React framework is gaining in popularity because of their virtual DOM concept. If you are looking at optimizing, I'd start looking into us using better Angular patterns.

[jmkao]

I agree, I don't think there's any performance reason to do this. My main motivation is to make it easier for slicer integration to have a dedicated and unambiguous place to get the data a slicer would need, rather than trying to figure out which of the 3 different fields that might potentially have X/Y resolution information is actually the one that needs to be used. It would also be a place to hang and future slicer integration interfaces.

[WesGilster]

To be quite honest, I don't understand why we have three of them! :)

I've only copied them over from Creation Workshop, maybe it's time we lighten the load of the actual objects and thin them to where they should be?

[jmkao]

Yeah, that's a dilemma. Those come from the format of machine definitions in Creation Workshop.

It wouldn't be that hard for me to go through and look to see which of those fields were actually used elsewhere in code, and then remove the unused ones. Although, would that impact our ability to load machine files created in CW?

[WesGilster]

We can leave the annotations and fields in the code and it will still parse the xml from CreationWorkshop. Then what we can do is turn off all of the extra fields for json marshaling. We get the best from both worlds that way Creation Workshop XML and thin json. Our biggest question is what to do when those three number happen to conflict each other from CreationWorkshop?

[WesGilster]

I suppose we pick the largest number and use it as the master?

[jmkao]

I'm thinking that all those fields should be ignored. Since we don't have any offline usage modes (e.g. you can't slice w/o printing), we should always use what's detected from the display software.

[WesGilster]

I think that's not a bad idea at all.

[WesGilster]

XResolution and YResolution that are inserted into Machine profile are being autodetected. We are also using and displaying X/Y density values from calibration. Those density numbers can be edited manually in the Advanced Printer settings in cwh-1.0.0-beta3.