@e_cubed99 I'm sorry, the command you mentioned should work, but there appears to be a bug in the plugin that handles network management. I just fixed it for the next version.
For the moment you need to edit /opt/dsf/conf/http.json and change the URL from port 80 to 1000. When done, restart the Pi or the web server (sudo systemctl restart duetwebserver).
@davidjryan It really depends on what you actually need to capture. In summary:
If you need to capture ALL error messages, you need to intercept ALL codes in "Executed" mode and inspect their result whenever they come in. I suggest you have a look at the CodeLogger utility and check if that is what you want.
@stuartofmt Thanks for pointing this out, I've got a fix ready. For now you can set first=0 to get a properly formatted response which should match the RRF format.
@davidjryan Generic messages come in via the messages[] array of the object model. You need to subscribe to OM changes in order to capture them.
@mikeabuilder The behaviour you're describing can be expected in standalone mode. The reason is that RRF does not return responses for each specific G-code request yet even though this is planned: https://github.com/Duet3D/RepRapFirmware/issues/925 We should be able to implement it in version 3.7 or 3.8.
I just changed the message box code in DWC 3.6 to avoid waiting for G-code replies of M292. This effectively fixes the issue you described in standalone mode, but I will not port it to newer versions because of the FR I mentioned. This is not an issue in SBC mode because the API is different - matching G-code replies are already returned there as part of the HTTP response.
@stuartofmt said in http /machine/connect session timeout:
Compare this to rr_connect which has a session timeout of 8000 seconds.
I guess you mean ms here - that's what the value indicates.
@stuartofmt If you do not have a password set and don't specify a session key, then there should be no need to use one. For the same reason requests like /machine/model work from a plain browser tab. If you have a password set, there is no alternative, though. The reference implementations all depend on those keys because we cannot assume users never specify passwords.
In addition to that, the session timeout is configurable via /opt/dsf/conf/http.json - see SessionTimeout in there.
@oozeBot Thanks for pointing it out, I just removed the section about gpiochip4. The automatic change in config.json to gpiochip4 was removed last year and that change is already in the latest DuetPi version, so no further changes should be needed at this point if the stock image is used.
@davidjryan Thanks for reporting this. It will be fixed in the next version.
@umutduman It sounds a lot like you fried the MCU with your custom circuitry. The MCU should never get hot, but if you overload the pins or connect more than +3.3V to them, that will physically damage the processor. So I think a MCU replacement is your only option. I'd be quite surprised if you managed to damage the MCU only by configuring the SPI peripheral or DMA wrong.
@jltx You can access logs using journalctl (e.g. journalctl -u duetcontrolserver -e) but I doubt anything else will show up there. Do you have any other applications running on your SBC? The message you got means something blocked the main process on the SBC from performing a data transfer.
@jltx I'm sorry but DWC no longer supports old Safari or Internet Explorer versions.
@jltx M929 isn't really needed in SBC mode because journald already keeps track of most important messages. When did you flash your microSD card? Is it rated A1 or A2? Can you confirm that vcgencmd get_throttled via SSH/terminal outputs 0x0 (not throttled)?
If you are still using the Debian Buster-based image, it's time to upgrade: https://docs.duet3d.com/en/How_to_guides/SBC_Buster_to_Bookworm
@oozeBot We have some more background information about the cause of this problem; it appears to affect the 6HC/6XD only. @dc42 is going to improve the upgrade mechanism in 3.6.0 stable.
On behalf of the Duet3D team I am pleased to announce the availability of version 3.6.0-rc.2. This is likely to be the final release candidate before we release our software as 3.6.0 stable, so please do test this build to avoid unexpected complications. If you find any issues, please open a new thread with [3.6.0-rc.2] in the title.
As always, please check the release notes notes first for
This task can be simplified using the ReleaseMgr plugin, too.
Users in standalone mode can upgrade by uploading the firmware bundle from here.
Users in SBC mode may need to change to the unstable package feed before upgrading all packages (e.g. via M997 S2). Please note that M997 S2 does not work on deprecated Buster-based Debian/DuetPi images. See here in case you need to upgrade.
If you are happy with this release candidate, feedback in this thread is welcome!
@stuartofmt I wouldn't recommend Telnet in SBC mode, it's insecure. In SBC mode, the DuetPiManagementPlugin only tries to activate the Telnet server via xinetd.
If you need a TCP port to send/receive G-code data, you'll have to write a plugin for SBC mode or wrap it around the HTTP API.
PS: It might actually suffice to forward a TCP port to the CodeStream/CodeConsole application in /opt/dsf/bin. Those utilities use the Telnet G-code channel by default.
@Serbitar This is going to be fixed in the next release candidate.
@achrn said in dsf-python-3.6.0rc1 http endpoint not working for me:
await http_endpoint_connection.send_response(200, "so happy you asked for it!")
This call looks wrong to me. I think you need to specify a third parameter like HttpResponseType.PlainText to actually send out data. Otherwise you only return a status code.
@moth4017 The display precision is set by the number of decimal places to display for Z. If you increase it to three digits in the settings, your custom value should be displayed correctly.
@achrn It should be available via the package feeds as well now.
