Schedule update process in Photonic

[kevinlan]

I got a LCD UV resin printer, control lamp with M106 S0 and M106 S255. Raspberry pi 3 and Raspberry Pi System Image on https://photonic3d.com/downloads/ (version 1.0.13) installed. I'm trying to print from .cws file contains png files, first layer is okay, but when first layer finished, lift up and down, the print job will stop and shows: Status: Failed Your printer configuration isn't capable of this featureCreation Workshop Scene Just can't figure out where the problem is , help please.

LogBundle (6).zip

[kloknibor]

Hi @kevinlan ,

I just checked your log files. This is the part where it goes wrong (to make it easier for the others) :

2016-12-04 13:49:18,908 INFO o.a.r.g.GCodeControl [PrintJobProcessorThread-2] Sleep complete 2016-12-04 13:49:18,910 INFO o.a.r.g.GCodeControl [PrintJobProcessorThread-2] Write 0: M106 S255

2016-12-04 13:49:19,011 INFO o.a.r.g.GCodeControl [PrintJobProcessorThread-2] lineRead: ok

2016-12-04 13:49:19,015 ERROR o.a.r.j.PrintJobManager$JobCloser [PrintJobProcessorThread-1] Job Failed:PrintJobProcessorThread-1 java.util.concurrent.ExecutionException: org.area515.resinprinter.display.InappropriateDeviceException: Your printer configuration isn't capable of this feature at java.util.concurrent.FutureTask.report(FutureTask.java:122) ~[?:1.8.0_65] at java.util.concurrent.FutureTask.get(FutureTask.java:192) ~[?:1.8.0_65] at org.area515.resinprinter.job.PrintJobManager$JobCloser.run(PrintJobManager.java:42) [photonic3d.jar:?] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:1.8.0_65] at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:1.8.0_65] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [?:1.8.0_65] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [?:1.8.0_65] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [?:1.8.0_65] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [?:1.8.0_65] at java.lang.Thread.run(Thread.java:745) [?:1.8.0_65] Caused by: org.area515.resinprinter.display.InappropriateDeviceException: Your printer configuration isn't capable of this feature at org.area515.resinprinter.gcode.GCodeControl.executeGCodeWithTemplating(GCodeControl.java:212) ~[photonic3d.jar:?] at org.area515.resinprinter.job.CreationWorkshopSceneFileProcessor.processFile(CreationWorkshopSceneFileProcessor.java:205) ~[photonic3d.jar:?] at org.area515.resinprinter.job.PrintJobProcessingThread.call(PrintJobProcessingThread.java:38) ~[photonic3d.jar:?] at org.area515.resinprinter.job.PrintJobProcessingThread.call(PrintJobProcessingThread.java:11) ~[photonic3d.jar:?] ... 6 more 2016-12-04 13:49:19,020 DEBUG o.a.r.p.PrinterManager [PrintJobProcessorThread-1] Attempting to dissassociate job:HollowCube.cws assigned to printer:Mini-Q LCD(printerFirmwareSerialPort:/dev/ttyACM0, projectorSerialPort:null Display::0.0) from printer 2016-12-04 13:49:19,021 INFO o.a.r.p.PrinterManager [PrintJobProcessorThread-1] Disassociated job:HollowCube.cws (No Printer) from printer:Mini-Q LCD(printerFirmwareSerialPort:/dev/ttyACM0, projectorSerialPort:null Display::0.0)

I can't tell you what exactly goes wrong... The M106 S255 is received by your printer and it returns an ok. Directly after that OK your printer seems to die :/ Hopefully one of the others can help you better!

Kind regards

[WesGilster]

Sorry, didn't see this till now. You are experiencing a bug where the gcode has a blank line or missing line and we throw an exception. You are using: 1.0.13 and this was fixed in the latest version: 1.0.14. Restart your Raspberry Pi and it should download the latest version.

    public String executeGCodeWithTemplating(PrintJob printJob, String gcodes) throws InappropriateDeviceException {
        Pattern gCodePattern = Pattern.compile("\\s*([^;]*)\\s*(;.*)?", Pattern.CASE_INSENSITIVE);
        try {
            if (gcodes == null || gcodes.trim().isEmpty()) {
                throw new InappropriateDeviceException(MachineConfig.NOT_CAPABLE);
            }

[kevinlan]

Hi WesGilster, I'll try 1.0.14, thank you.

You did a great job 💯

Regards

[WesGilster]

Thanks for the kind words. Let us know when you get everything working.

[kevinlan]

Hmm... There is no upgrade running to 1.0.14 when I turn off my raspberry and turn on again. Then I ssh into raspberry and run sudo ./start.sh manually, the upgrade task starts. It seems like a problem because 1.0.14 were released 24 days ago, but I install raspberry image these days , It should be updated when I boot with Raspberry Pi System Image first time.

I do a dry run after upgrade and it works like a charm, so I printing my size calibration model now.

Thanks again.

[WesGilster]

Let me make sure I understand what is happening here. You run this manually from SSH: sudo ./start.sh

...and it upgrades fine, but when the Linux starts Photonic as a service through: /opt/cwh/start.sh

it fails to upgrade?

[kevinlan]

I have a new installed raspberry image , service runs but no upgrade (1.0.13). But when I run sudo ./start.sh from SSH, the upgrade succeeded (1.0.14). I will reinstall my raspberry to confirm it.

[WesGilster]

Wow that's weird, given that both situations simply run the same start script. I know your original problem is solved, but I'd be very interested in the recreation scenario for this.

[kevinlan]

That's what I have been done. 1.I got a Raspberry Pi 3 (model B), downloaded image file (2016-09-23-raspbian-jessie-lite.img at that time) 2.Write image file into micro SD card use Win32DiskImager. 3.Edit octopi-network.txt to configure wifi, write file ,ecjct SD card. 4.Insert SD card to Raspberry Pi 3, turn on the power. 5.Open http://photonic3d.local:9091 in a browser. 6.Confirm the version 1.0.13 at lower left of dashboard page. 7.Turn off power, wait a while , turn on the power again. 8.Still got 1.0.13 at dashboard page. 9.Follow Linux Installation sudo wget https://github.com/area515/Creation-Workshop-Host/raw/master/host/bin/start.sh sudo chmod 777 start.sh sudo ./start.sh 10.Got upgraded cwh 1.0.14

I found if doing sudo /opt/cwh/start.sh on nonupgraded system, it does the same thing as sudo ./start.sh does. But I still don't understand why 1.0.13 can't upgrade itself?

[jmkao]

The problem with the unreliable update at startup has to do with a related problem that we found in area515#225.

Depending on the network conditions, cwhservice can be run before the network attach and DHCP process is complete. When that happens, the curl call to check whether there is an update available will fail.

Previously, that resulted in the service not starting at all, but in https://github.com/area515/Photonic3D/commit/1dd7ceb29bbddfb5402e054136da58dc1ef1937a, I added a little fallback logic to simply start the existing version if the network cannot be reached.

The simplest enhancement here, to make start.sh try a little harder to get an update, would probably be to add in a curl retry parameter to https://github.com/area515/Photonic3D/blob/master/host/bin/start.sh#L113, maybe something like --retry 10 --retry-max-time 30

Probably need some testing on an afflicted system to see if that works.

[WGAndrew]

We hit this same issue on the Photocentric branch and I implemented a blocking wait for network access.

not the best option, but might be another alternative: https://github.com/Photocentric3D/Photonic3D-Dev/blob/master/host/bin/start.sh Function is at Line 5 Usage is line 116

[jmkao]

A blocking check seems drastic, since you would be unable to start at all if your system if it were disconnected from the Internet, and render the software inoperable if you were located in an offline location or chose not to connect your system to the Internet.

That's also the fundamental trade off for retry logic, since it creates a startup penalty for offline setups.

[WGAndrew]

Sorry, should have said there's a timeout - it doesn't just completely block forever. :)

There is an unfortunate hit to offline printers with that block waiting - but then that's been accepted as a realistic trade-off. There's no good solution to knowing whether a network will eventually be accessible, and having automatic updates on boot was felt to be worth the small time sacrifice for non-networked printers.

[jmkao]

Hmm.. given that curl has built-in exponential back off, retries, and max retry total time capability built in, what advantages do the custom retry function give?

[WGAndrew]

using ping is more lightweight, which is always welcome on the Photocentric builds!

I'm also not sure I'd 100% trust curl if the network environment involves filters or proxies. (Not a slight on curl - just based on some really odd recent experiences with apt-get for proxies in certain network environments too.)

At the end of the day, YMMV, but that solution's been working well for us.

[jmkao]

The question is around what we're trying to achieve in the network check. A standalone ping direct to github checks something different than retrying the actual call to retrieve version info.

If all we care about Internet access for is the download of new versions, then a curl retry would be the shortest path to that, since it checks exactly what we need, since curl is what's used to actually download the version info.

However, if there are other network path checks necessary, those might require additional types of checks that could be encapsulated in a dedicated function, although I currently can't think of any of these offhand.

[WesGilster]

Something is bothering me a bit. Correct me if I'm wrong Kevin, but I don't believe @kevinlan is talking about an offline printer that won't auto-upgrade. You guys seem to be implying that the Photonic3D service(cwhservice) starts before networking capabilities have been bootstrapped? If so, then we simply need to change our service dependencies to depend on OS networking and we are good. Otherwise I need a bit of help to understand why it's a bug when we don't auto upgrade in an offline scenario. I'm a little late to the conversation, so sorry for having to get me up-to-speed.

[WesGilster]

Sorry, you addressed this in #225. So our fundemental problem is determine the ambiguity between network bootstraping incomplete and network will not be available.

[WesGilster]

I wrote a restful service for a printer in offline mode long ago if you guys are interested in it. I never really used it. Photonic versioning and network upgrades have changed a ton since then, so you'll need to test: http://localhost:9091/apidoc/#!/machine/stageOfflineInstall

I feel like we are trying to push a feature "upgrade-on-startup" when that might not be a sound theory. In other words, how do we know the difference between a printer in internet offline mode, a printer that is still bootstrapping DHCP and/or a printer where the user changes their mind periodically.

It wouldn't take long to implement a org.area515.resinprinter.plugin.Feature that looks for new releases in a scheduledExecutor on a configurable interval. That way the feature could be enabled/disabled from our config file like the rest of the features. When an upgrade is found we could send back a notification through the websocket that a new upgrade is available. Giving the user that ability to perform the upgrade at will, or when the printer is inactive.

Let me know what you guys think...