DuetLapse3

stuartofmt

Thanks - there was a silly formatting error (now fixed) but underlying that it looks like there was an http 405 error returned.

I've added a two more version of the send gcode function to try - hopefully one of them works. Unfortunately the documentation and other examples (which purport to work) are somewhat vague on this aspect ....

ALSO - if you are running RRF3.2 the default behavior for CORS seems to have changed. With another program I am using (DueUI) - I had to add the following to config.sys (up front in the network section) - after the upgrade. BUT DuetLapse was unaffected. It MAY be different on SBC.

I'd suggest first trying "as is" but if this script still does not work with one of the methods (depending on what the errors are) - the CORS thing may need to be looked into.

M586 C"*"                                     ;enable CORS

New Test Script is here

~~[SBCTEST.py]~~

fractalengineer

Awesome Stuart, thanks for carrying on Danal's work

Looks well documented too, I'll give it a shot over the weekend.

Very neat of you to handle issues outside of your own setup too

Do you think in it's current state this could realistically be implemented as a plugin in DWC for a possible GUI?

stuartofmt

@fractalengineer

Thanks. As a plugin ? hmmm . I'll have to see what that means / entails. Let me put that as a priority 2 for right now.

Priority 1 is getting SSB working and tidying up some of the logic / behavior surrounding pauses. I did not test that aspect much and its somewhat ambiguous - so stay tuned ...

jay_s_uk

@stuartofmt

192.168.1.31 Determine API Version
192.168.1.31 Testing: rr_model at address 192.168.1.31
192.168.1.31 http://192.168.1.31/rr_model?key=boards
192.168.1.31
192.168.1.31 Testing: /machine/system at address 192.168.1.31
192.168.1.31 http://192.168.1.31/machine/status
192.168.1.31
192.168.1.31 API model is: SBC   Version is: 3
192.168.1.31 Status is :idle
192.168.1.31 Layer is :0
192.168.1.31 ***Testing V0***
405
Method Not Allowed
192.168.1.31 gCode command return code = 405
192.168.1.31 Method Not Allowed
192.168.1.31 Send Gcode result: 405
192.168.1.31 ***Testing V1***
200
OK
192.168.1.31 Send Gcode result: 0
192.168.1.31 ***Testing V2***
404
Not Found
192.168.1.31 gCode command return code = 404
192.168.1.31 Not Found
192.168.1.31 Send Gcode result: 404

stuartofmt

@jay_s_uk

OK! Looks like V1 worked!! So you should have got a message on DWC saying "Test of SBC"

Did you see that ?

jay_s_uk

@stuartofmt
No, nothing displayed on DWC

stuartofmt

@jay_s_uk

Ok - I'm going to have to get some help. The code I have seen elsewhere (including Danal's) does not work (or I've done something stupid). The one that reports success - does not seem to send the gcode .... go figure .....

So - this should work for SBC -- but not for using the pause capability (that's the only thing that sends gcodes). ~~Appreciate it if you could test before I update github~~

Hmm - wont let me upload the file to here. I'll update on github - if you would not mind downloading from there.

stuartofmt

Ok it looks like we are getting close ( thanks to an "anonymous" tip in another thread )

Can you try this please. V3 is the latest (and hopefully correct) form.

~~[SBCTEST.py]~~

stuartofmt

In order to better handle pause situations - I need to access Duet to get a previously unused set of parameters. I'll post a new test script tomorrow. If successful - then SBC should be fully supported. Stay tuned and thanks for the help.

PCR

@stuartofmt i will have acces to my SBC printer tomorrow

stuartofmt

If all y'all could try this on SBC please

~~[SBCTEST.py]~~

In particular verify that a message appears in DWC "Test of SBC"

jay_s_uk

@stuartofmt
Good news

Determine API Version
localhost Testing: rr_model at address localhost
localhost http://localhost/rr_model?key=boards
localhost
localhost Testing: /machine/system at address localhost
localhost http://localhost/machine/status
localhost
localhost API model is: SBC   Version is: 3
localhost Status is :idle
localhost Send Gcode result: None
localhost Layer: None
localhost Get Position X and Y: 160 130

bad news, no popup

stuartofmt

@jay_s_uk

Yikes on the lack of gcode being sent ... Unfortunately the API endpoint reports success - when clearly that is not the case ...

This one last bit is turning out to be frustrating ....

The code for sending the gcode (thanks for the reference) is very simple. It works perfectly for rr_model (just uses a http get) but does not seem to want to play for /machine/gcode (which according to the doc requires a post).

I've added a second slightly different syntax. I found two slightly different versions (one in DuetUI and the second in Danals DuetAPI). They are nearly identical, one has the url as .../machine/code and the other as /machine/code/ ...

If you would not mind running it .....

SBCTEST.py

jay_s_uk

@stuartofmt
no popup there either

localhost Determine API Version
localhost Testing: rr_model at address localhost
localhost http://localhost/rr_model?key=boards
localhost
localhost Testing: /machine/system at address localhost
localhost http://localhost/machine/status
localhost
localhost API model is: SBC   Version is: 3
localhost Status is :idle
localhost URL was: http://localhost/machine/code
localhost Send Gcode result: None
localhost Layer: None
localhost Get Position X and Y: 160 130
localhost URL was: http://localhost/machine/code/
localhost Send Gcode result: None

stuartofmt

@jay_s_uk

I'll go back to the DWC threads and see if there are some ideas I can try.

The good news is I've made the baseline code considerable more robust and have improved the handling of pauses (if used). But none of the pause improvements matter without the ability to send gcodes

PCR

@stuartofmt
https://github.com/Kriechi/Cura-DuetRRFPlugin/blob/master/DuetRRFOutputDevice.py

Maybe this is helpful

PCR

@stuartofmt only for history

pi@duet3:~ $ ./1610998509032-sbctest.py -duet 192.168.140.126
192.168.140.126 Determine API Version
192.168.140.126 Testing: rr_model at address 192.168.140.126
192.168.140.126 http://192.168.140.126/rr_model?key=boards
192.168.140.126
192.168.140.126 Testing: /machine/system at address 192.168.140.126
192.168.140.126 http://192.168.140.126/machine/status
192.168.140.126
192.168.140.126 API model is: SBC   Version is: 3
192.168.140.126 Status is :processing
192.168.140.126 URL was: http://192.168.140.126/machine/code
192.168.140.126 Send Gcode result: None
192.168.140.126 Layer: 3
192.168.140.126 Get Position X and Y: 96.787 119.675
192.168.140.126 URL was: http://192.168.140.126/machine/code/
192.168.140.126 Send Gcode result: None

no DWC message either

PCR

@stuartofmt I changed this line

logger.info('Send Gcode result: '+str(sendDuetGcode2(apiModel, 'M117 Test of SBC')))

to

logger.info('Send Gcode result: '+str(sendDuetGcode2(apiModel, 'M117 "Test of SBC"')))

aand

stuartofmt

@PCR said in DuetLapse3:

logger.info('Send Gcode result: '+str(sendDuetGcode2(apiModel, 'M117 "Test of SBC"')))
aand

![a02d93f9-98a1-4404-bb9a-c67b729cac68-grafik.png](/assets/uploads/files/1611049373109-a02d93f9-98a1-4404-bb9a-c67b729cac68-grafik.png)

Brilliant!.
Last night (in my slumbers) I wonderer if the data=command in the push code needed to be encoded because of the spaces in M117 etc. In the various example code it seems only single gcodes have been passed and likely why those examples worked. Dueui was a bit different but that was javascript and I'm even more unfamiliar with that than I am with Python .....
DuetLapse3 in its current form only needs to send single gcodes. So - as it stands we have a fully working DuetLapse3. The choice of M117 ... for testing turned out to be both good and bad.

What I will do today is try and crack the encoding needs so that it does not break in the future. I've set up a simple webserver and can debug the incoming and see what happens. I have not yet updated the github but either way will do so later today

@jay_s_uk and @PCR
Thanks for being the remote testers.

stuartofmt

Version 3.0.4 released in github. All functionality should now work with SBC.

The issues with SBC gcode appear to be due to differences in the way DWS was handling the test case.