Posts made by EasyTarget

@oliof said in Time to depreciate Thingieverse due to Stratasys:

(in 2024, Stratasys owns less of UltiMaker and thingiverse than two years ago.

Hence the 'part owned', I get that it's a complicated relationship and I do know about the recent acquisitions.

I actually considered the fact that UltiMaker properly funded Thingieverse again to be good, and started uploading there again after a couple of years when the site was so broken uploading was not worth the hassle.

But.. UltiMaker are still part owned by Stratasys, and therefore Stratasys derives benefit from the community. I think it appropriate to think again about who I provide traffic to.

You need to read the Toms hardware article for the detals of this pathetic IP land-grab; but the long and short of it is that Stratasys are trying to enforce, among other things, a patent for using a heated bed in 3d-printing. I wish I was joking..

https://www.tomshardware.com/3d-printing/3d-printer-maker-bambu-lab-faces-patent-infringement-lawsuits-that-could-threaten-hobbyist-3d-printing-in-general

Thingieverse is owned by UltiMaker, in turn part owned by Stratasys. One way to show our collective displeasure is to pull designs from there and go to cults, prusa etc. since they are less toxic to the community.

This is my plan, anyway.

There is, of course, a vigorous discussion to be had over this. What might concern Duet3d in particular are the following claims:
US9168698B2 - Three-dimensional printer with force detection
US10556381B2 - Three-dimensional printer with force detection

@dc42 Thank You, I'd hoped it was a trivial fix of this sort.
I have also added a 'do not check firmware' init() option to serialOM since it's a bit redundant in some situations.

As the title implies, if I run M115 while my board is in 'simulating' mode, the command prompt returns immediately with ok instead of the expected data.

RRF 3.5.2 on Duet2 WiFi

<connected via pyserial-miniterm -q>:
----------------
M115
FIRMWARE_NAME: RepRapFirmware for Duet 2 WiFi/Ethernet FIRMWARE_VERSION: 3.5.2 ELECTRONICS: Duet WiFi 1.02 or later FIRMWARE_DATE: 2024-06-11 17:13:43
ok
M37 P"0:/gcodes/bailer.gcode"
Simulating print of file 0:/gcodes/bailer.gcode
ok
M115
ok
M115
ok
File 0:/gcodes/bailer.gcode will print in 0h 57m plus heating time
M115
FIRMWARE_NAME: RepRapFirmware for Duet 2 WiFi/Ethernet FIRMWARE_VERSION: 3.5.2 ELECTRONICS: Duet WiFi 1.02 or later FIRMWARE_DATE: 2024-06-11 17:13:43
ok

I cannot see any other modes where this fails to respond, eg it works when processing a job. It just seems to be simulating that kills it. RRF 2.4.6 behaves in the same way.

Is this intentional? it caused some confusion since serialOM uses m115 to detect that it is connected during init().

edit: I checked docs and did a forum and google search and cannot find anything related there

@airscapes
apopos to nothing.. I've been doing this for some parts with good success (I manually pause the machine at the appropriate moment.. small parts..)

I have found it helps to pre-warm these metal washers on the printbed, before dropping in with tweezers while hot. Seems to help once the next layer goes down on top of it, if cold they can lift and snag the nozzle.

Related; I've been connecting to my Duet@ Wifi over USB and serial a lot recently; but also over telnet (all while working on SerialOM, which actually started out as a telnet client).

I have seen similar behaviour on all serial connection types, after a restart random chars appear in the input buffer of the duet. I have seen this on uart, USB-Serial and telnet connections, but is is very ephemeral and random. SerialOM actually has code in it's startup that sends a couple of \n's and ignores the response at startup; I added this specifically to address this issue.

I have a 'gut feel' that something is wonky with the input and output buffer initialisation at startup. Possibly the internal MCU UART registers themselves not being properly reset and cleaned during resets? This is a guess on my part, based on observed behaviour, reality may differ substantially.

This is an example from last Tuesday; I'm connecting to my D2wifi via USB serial from a Pi3 using pyserial-miniterm.

--- Miniterm on /dev/ttyACM0  9600,8,N,1 ---
--- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---
g time
File 0:/gcodes/bailer.gcode will print in 0h 56m plus hea
Error: Bad command: WiFi module is ce
ok

Context: This is a connection to the board via USB serial immediately after it was rebooted.
Before the reboot I had just finished simulating a print via the Web interface.
As you can see the Input buffer on the Duet appears to have text in it that was actually written to all serial devices before the restart when the simulation finished.
The Duet2 is still running 2.4.6, but I have seen this with earlier releases too

A quick note that I just published a small update as release: v1.2.0

This removes the need to have a the separate compatLib.py library present; all the cross-python handling is now done in serialOM.py itself. Nothing else is changed.

I have created PR489 for this with my changes.

Disclaimer; I'm not a native Dutch speaker and have never worked in a workshop here, so I may have missed things, used wrong terms or made other mistakes.. Still, it should be better than before

@brampie if you have a GitHub account you can comment on the PR (if @chrishamm wants to hold the PR for a few days to gather comments).

Humm,

'close' is 'dichtbij', which means 'nearby', not 'shut'. It's all a bit 'auto translated'..

The translation matrix is nice and easy to understand here

It's 'kings day' in Holland today, I'm wearing orange and just off for a beer in Amsterdam. I'll see if I'm feeling sober and patriotic enough to submit a patch later.

@Arminas
You definitely should ground the hotend on a 3d printer, the effect of pushing plastic through tubes and nozzles will cause static buildup and possibly sparks.

But do not ground it directly, instead use a high value resistor (100K / 1M) to bond it. This will safely deal with the static, but helps to protect the printer against accidental shorts (frayed wires and case defects) between thermistor or heater leads and the hotend.

I'm sure I saw this advised here long ago, but couldn't dig up a reference.

@o_lampe said in Delta mechanism as router:

Maybe I chose the wrong words, but with engraving I meant using a small router and a chisel

No, my misunderstanding. I forget that there is more to engraving than lasers..

And you are right, there is a load of light rotary engraving that could be done.. PCB cutting and drilling springs to mind.

@o_lampe said in Delta mechanism as router:

A feltpen-plotter might work, but not a router. Engraving might work, too.

TL;DR;

Thats very very much what I was thinking, other options include a Knife-Cutter (especially if you have a spare stepper to rotate a flat knife instead of a drag-knife).

or get a cheap lightweight 5/10w Diode laser online, I think the deltas speed is a really good fit for laser engraving, especially for image rastering (doing them line-by-line) and filling areas.

• caveat: a full light-proof enclosure is a must, with external ventilation. Even paper and wood have glues and additives that are harmful, plastics can be deadly.
• wiring and setup should be easy, chose a module that matches your motor voltage (12/24v) and iirc there are excellent wiring and config guides in the Wiki.
• PS: I really mean it about the enclosure; but the good news is that diode lasers are focussed, their beam rapidly diverges, and their 'base' power is low (2.5w diode with good focus is sold as a '10w' (equivalent) module. This means a 'heath-robinson' enclosure is acceptable. Good cardboard and packing tape will be fine. Put a USB webcam in to follow progress.
• PPS: I'm a big proponent of 'compressed' Diode Lasers over on makerforums.info, but also a big detractor; they are useful, and fun, but have big limitations, serious safety concerns and are then horribly oversold to the gullible online. Like a sharp knife they need a sharp user.
• disclaimer/spam: I'm biased towards the above. I'm the maintainer of LaserWeb, I own two diode laser machines and am a moderator at https://forum.makerforums.info/ Which is a good place to go for help and advice on general laser, CNC and workshop mechanics and use.

@dortyuz The issues you may encounter are not controller related; as noted above RRF will do this very well (I once used my delta for laser engraving very successfully).

The issues are likely to be mechanical, and very dependent on your build and what you plan to cut.

I (personally) do not think the delta mechanism is a good fit for the sustained sideways loading of a router. You should at least have the spindle passing through the delta effector plate to keep the bit as close to it as possible (motor above plate, chuck/collet below) and minimise the twist you are applying here.

Also calibration needs to be really spot-on to get good dimensional accuracy on delta mechanisms, depending on what you need to cut, and what it needs to fit to, this could become a issue.

For anybody who does make a sand table, there is a dedicated online gcode generator for them here:

https://sandify.org/

Unfortunately it does not have a 'cat' mode..

@loddie said in Is streaming G-code (real-time) possible?:

Is it possible to stream G-code data into Duet3D controller boards instead of loading from a file?

If so, is there any feedback mechanism such as checksum or "OK" to notifier the sender that the data was received?

Yes, and Yes.

You can send gcode directly to the Duet via USBserial, or via hardwired uart serial, also via telnet and other streams too.

You can choose to use checksumming and message sequences to ensure integrity.

Look in the duet documentation for examples and descriptions of this. Almost ALL other firmwares can do the same.

Doing this is very common, especially on non networked controllers, it's how OctoPrint works, for instance.

@berniej Thankyou! I'm glad if this is useful for others.

Please note that I have just done some tweaks to the response reading and sequence processing that address a couple of concerns I had, it should be less liable to briefly de-syncing when console (or json) status messages arrive.

There is a new release, v1.1.0 in the repo, the changes are all internal, usage has not changed.

Finally; I got to do some gc.mem_free() data gathering at various points in the loop under micropython; I max out at about 24K total additional RAM consumed by the serialOM loop; even when I have cycled the controller through three modes and run a simulation in each to fully populate the local OM with typical data.
I'm pretty happy with this, better than I expected.

Hi all; this is something I have been working on to power my PrintEYE replacement but it took on a life of it's own and I'd like to get it out of my system.. so here goes.

serialOM.py is a self-contained python class that connects to the OM on a RRF device via USB or UART, and provides a local copy of the OM that can be periodically updated.

https://github.com/easytarget/serialOM

The readme there does a proper TL;DR but the highlights are:

• Python3/microPython cross-compatible with both PySerial and the mpy UART support
• Keys to be fetched can be specified on a per-mode basis and the 'seqs' key is used to only do verbose fetches when needed.
• Controller reboots and mode changes are handled appropriately. soft failures (timeouts) are tolerated and detectable. Hard (comms port) errors trigger a custom exception.
• more.. see readme.

Basic use can be as simple as:

from serialOM import serialOM
from serial import Serial

rrf = Serial('/dev/ttyACM0',57600)
OM  = serialOM(rrf, {'FFF':[],'CNC':[],'Laser':[]}, quiet=True)
print('state: ' + OM.model['state']['status']
     + ', up: ' + str(OM.model['state']['upTime']) + 's')

There is an associated printPy program that implements a robust logging / console info loop. It reconnects as USB ports change etc. and logs human-readable print/CNC/Laser status, value and progress data to the console and an optional file.

I consider the CPython side of this 'done' (unless bugs.. quite likely because I'm no Pythonista), it runs well from a Pi3 with a USB connection to my Duet2 WiFi.

There is a work in progress microPython version of this loop; printMPy which can do the same console output, but also has RGB 'mood/activity' light control and button/status controls being implemented.

Both of the print*Py loops use a separate output class. currently the same 'TXT' demo works on both. This is a template for my in-progress I2C output class can be run in a thread to allow screen animations independent of the serial comms.

@chrishamm

@chrishamm said in ObjectModel `seq` responses when in SBC mode?:

it's passed through and interpreted by RRF:

AAh, brilliant, thanks for the response.

I guess this was just me getting confused about what 'exposed' means; I just twigged it means 'exposed to the DSF' as opposed to exposed to M409.

I can now strip my 'SBC mode' functionality out.. less complex == more good.

A quick question; can someone with a Duet in SBC mode tell me what the response to a ObjectModel seqs key request looks like?

M409 F"vnd99" K"seqs"

eg; is it {"key":"seqs","flags":"vnd99","result":{}} or {"key":"seqs","flags":"vnd99","result":null}, or something else??

I'm working on code that queries a list of OM keys, and following the OM documentation:
https://docs.duet3d.com/User_manual/Reference/Gcodes#m409-query-object-model
Which says this:

In standalone mode, each main key (like boards or heat) has its own sequence number in the seqs key which is not documented here. Whenever a non-live field is updated (see M409 F"f"), this sequence number is increased. For clients targeting standalone mode, it can be helpful to check these values to determine when it is time to request a full key from RRF again. There is an extra value seqs.reply as well which is used notify clients about new messages (see rr_reply). Note that these sequence numbers are not exposed in SBC mode

My code does the sequence processing properly when in standalone mode, checking for sequence changes for the keys it fetches and only doing verbose updates when needed.

But I'm keen to make sure it wont blow up if connected to a machine in SBC mode. Currently I check for a seqs key response of null or {} (empty dict.) and assume SBC mode in that case. But since I only have my humble Duet2 I cant test this, hence the above question.. I drew a blank trying to search for this.

@yngndrw You are right, I was a bit snarkyt there; you make a good point and as I have yet to begin porting from CPython to microPython, your words might haunt me when I do

I apologies for the last comment; we've recently had some similar stuff with fanboys/spambots on makerforums and I was translating that here. Mea Culpa.