@dc42 thank you for the information. I think I will checkout the version matching release 2.01 (d0505c8) as you suggest, then merge recent updates once the code has stabilised.
EDIT: I can confirm d0505... compiles. Thank you for your help.
@dc42 thank you for the information. I think I will checkout the version matching release 2.01 (d0505c8) as you suggest, then merge recent updates once the code has stabilised.
EDIT: I can confirm d0505... compiles. Thank you for your help.
You could re-slice with Slic3r, then use the flow calculations from the manual: http://manual.slic3r.org/advanced/flow-math
Today I decided it was time I moved up to v2-dev from 1.21. We use modifications to the firmware (still with a few kinks we need to iron out), so I need to have a working Eclipse setup.
Using 1.12 I was able to compile for SAM4E8E, but having switched to v2-dev I am getting stuck at the linker stage. I have checked out the v2-dev branch of CoreNG and succesfully built this and FreeRTOS. When I try to build RepRapFirmware, I get:
makefile:68: recipe for target 'Duet2CombinedFirmware.elf' failed
This error is buried among several warnings such as:
warning: undefined reference to `SmartDrivers::SetDriverMode(unsigned int, unsigned int)'
Has anyone come across this and can point me in the direction of a fix?
(Full console log is copied here.)
The G-Code console tab should provide you with a history of messages.
@Danal Thank you for your comments. I already played around with your MultiDuetWebMonitor. It looks good.
I am also considering polling from the remote server, but although that would give me data to draw some nice graphs, it wouldn't provide accurate data for print start/stop/cancel events and filament usage.
In a production scenario, the standard DuetWebControl interface wouldn't be running as print start commands would come from the remote server, so opening an intermittent outgoing connection from the Duet shouldn't add too much strain on its processes, but I agree this extra overhead will have to be investigated further and monitored.
Perhaps it would be safer to modify the data written to the eventlog on the SD card, and have the server poll the last line to check for new events.
We run a number of machines and are looking to collate the event log data on a central server. This will enable us to monitor machines, analyse the data perhaps eventually run a print queue from that server.
Looking at IoT dashboards, such as thingsboard.io (and there are many others), it appears that devices need to authenticate with the server before being able to send data.
I see a few people have discussed the idea of the Duet sending data, (https://forum.duet3d.com/topic/4285/g-code-to-actually-send-a-message, https://forum.duet3d.com/topic/4795/how-to-use-m118-to-send-http-requests) but no neat solution has been presented.
I think it would be useful to add a webclient class to RepRapfirmware to be used by M118 and M929 to send data to a remote server.
Before I tackle adding this myself, I wanted to ask whether anyone else is working on such a solution so as not to reinvent the wheel?
There are plenty of example code snippets online, such as http://lwip.wikia.com/wiki/Raw/TCP, which describe how to structure such a feature.