Posts made by jv43

Hardware DUet2Wifi v1.03
Firmware: 2.03RC5
WiFI Firmware: 1.23

My Duet worked fine for quite some time now, I did some prints 2 days ago.
When I tried connectng to my rinter today to print something I could not connect to DWC.

After multiple powercycles and resets I tried connecting over USB which worked fine but my duet would not let me connect to my network.
I tried restarting/resetting my router and deleting and adding my network again, no luck unfortunately.

I have included the log from my terminal in this post. the only edits are private data and a bunch of repeated messages denoted with "[...]".

Any suggestions to get my board working again?
I just received 5 more spools of filament..

Terminal Log

@notausername please take a look at the link David posted

@sputnikoc3d Please check out the changelog here

The fix you implemented regarding filament usage when using Prusalicer 2.0.0 works like a charm.
I'll let you know if I encounter any bugs.

@hbrownell
Motors:

• for the motors you mentioned I'd start with 1200-1300 mA

• 100 steps/mm doesnt look right to me please refer to this calculator to get the relevant values for your specific setup.
  same goes for Z steps/mm

• steps/mm on your extruder can be calibrated after you are setup:

1. measure and mark 150mm of filament from a fixed point (i.e. extruder body)
2. tell your printer to extrude 100mm of filament
3. measure again to determine the actual amount of filament extruded
4. calculate your new steps/mm using this formula: <current steps/mm> / <actual amount of filament extruded> * <length you wanted to extrude(100 mm in this example)>

Heater config

• for your V6 if you got the standard kit the values should be R25=100000 B=4725 C=7.06e-8
  But please look here for more detailed information to double check.

• for your heatbed, you will have to look up your specific model and the type of thermistor used. Check the datasheet of that thermistor to get your values.

BLTouch:

• Probe X and Y Offsets are the distance from your nozzle to the BLTouch, this depends on your mounting solution

• Trigger height is the distance from your nozzle to the bed once when the BLTouch triggers, this is also unique to your config and needs to be measured.

Fans:

• Fan0 should be your part cooling fan and should not be thermostatically controlled
• Fan1 config looks fine, if it does not work, try changing the PWM frequency.

@fma I wasn' talking about a corrupted sd card, but a corrupted file (maybe after unexected power loss during edit?)
M0 will work with no cancel.g/stop.g present and default behaviour is to shut off all heaters.

@gnydick I definately agree it would be better to put the gcode in the macro itself rather than having it be empty by default and have some other code run when no actual gcode is present in that macro, maybe @dc42 can give some insight why it was implemented this way (maybe for safety reasons if stop.g or cancel.g are not present/readable or corrupted in some way).
You're posting in tuning and tweaking, so I thought you mainly wanted to make it work.
In that case my suggestion would be to create cancel.g and add your code.

For fundamental changes to RRF I'd suggest you post in Firmware Wishlist.
David is currently working on RRF 3.0 and I think that thread is open for suggestions too.

@manne_sahne wouldnt a simple inverter IC work?
maybe get a hex inverter IC or a breakout board if you dont want to mess with small smd stuff

If the SD card you were trying to use works in another of your duets and cards working in those are not recognized on that board it looks like your slot is broken and you may need to RMA the board.

Another thing you could try is erasing the chip and doing a fresh firmware installation, maybe something is messed up with your firmware?

@gnydick running M0 with no H1 parameter shuts all heaters off. This is normal behaviour for any FW based on the RepRap FW and always worked that way afaik. I never used any other FW except for marlin, which is also based on RepRap, so i can't comment on the behaviour of other firmwares when executing M0.
This behaviour is documented on the RepRap wiki as well as the Duet documentation, so it does exactly what you instructed it to do?

So you want to use M0 with your slicer?
try

M0 H1

and add

M106 P0 S0

to your stop.g
please test if thats now behaving as you want it to.

@ben_van looks interesting, but what the heck is that?

When I start a new spool of filament I weigh it and mark the empty spool weight on the spool. When I'm going to start a print and it isn't obvious that there's enough filament on the spool, I weigh it again and subtract the empty spool weight. It works every time. I haven't run out of filament during a print in years.

I'm aware that's possible, I just think having an estimate of the amount of filament left on my spools would be neat, what if I'm not in the mood to break out a scale and my calculator?

Descriptions like "blue transparent" are nice, but you'll need a more positive identifier than that. What if you have more than one spool of "blue transparent" filament? I'd assign a serial number to each spool so I can be sure exactly which spool I'm looking at in the controller.

That's true, but I'd wager most people dont have multiple partly used spools of the same material, manufacturer and color in use at one time. Adding an ID for each spool could easily solve that but only an ID would be to cumbersome IMO.

It would be much better to integrate filament accounting into the slicer so it can warn you that there isn't enough filament left on that spool to finish the print.

I'd rather have that on my printer as I'm frequently switching slicers or device the slicer runs on, but not my printer. I think most people use multiple slicers/slice on different machines and not one slicer on one machine for multiple printers. Even IF I'd be only using 1 slicer I don't want to update a database on multipe machines everytime i slice a model.
Also what if I just slice a file and dont print it? what if I print the same gcode twice? what if a print fails and i have to restart it?
Only way that would make sense if you had a machine dedicated for sending out the gcode to the controller of your machine(sounds a bit like my Duet )
Implementing this in the Duet FW rather than a slicer makes way more sense IMO.
Also, IIRC this is the duet forums not the forum for some random slicer?

@gnydick what firmware version are you running?
I never added a "cancel.g" and i just checked, it's in my sys files.
I just added

M106 P0 S0

to my cancel.g and it turned off the part cooling fan, while keeping all heaters on.

yeah, that makes sense, but this feels like another example of assumed use case rather than the machine just doing what it's told. What If I didn't want the heaters to turn off at the end of the print?

Using cancel.g when cancelling a print seems like the machine IS doing exactly what it's told.
So I don't really see the problem in creating cancel.g or updating your FW

@gnydick

What If I didn't want the heaters to turn off at the end of the print?

There is a checkbox under "Job Control" named "Enable Auto-Sleep".
When checked, all heaters are turned off once a job has finished.

Edit: sorry i misread your post.
maybe auto sleep is checked?

@totalos

Now is 100 and 60 - in my opinion it is not safe

I second that! It really should be 5 and 5 at default, better to extrude too little and too slow than too much and too fast.

IIRC there once was a filament odometer suggested i.e. a figure what length of filament was extruded since the machine first went online/the last reset.
While thats kinda neat, I'd find another one really amazing:

We already have "Filament" config files vor loading and unloading (iirc we also had a "config.g" file per filament but I cant find that anymore), what if we could have an odometer for every spool?
We'd need to have a config file for every color/spool that specifies filament diameter, etc. maybe like this

;fil_type = PETG
;fil_manufacturer = XXXX
;fil_color = Blue transparent
;fil_dia = 1.75
;fil_density = 1.29
;fil_amount = 800
;cost = XX.XX

maybe we could even add

;fil_loadtemp = 230
;fil_unloadtemp = 200

and ditch the load.g and unload.g macros for each filament with one that specifies wait times, amount of filament extruded etc.

or maybe a .csv that acts as a "database".
as long and you'd use the load and unload function in DWC the firmware could keep track of how much filament was used for each color/roll of filament.

This would enable having a vage idea how much filament is left on your spool and maybe a warning if you are low on filament/do not have enough for your print.

Having diameter, amount of filament, density and cost in there would also enable accurate weight and cost per part as long as filament usage metadata is accurate.
These values could be displayed under "Job Information" in DWC.

Thoughts or suggestions?
Or is this a dumb idea/way too much work?

-JV

@dallash
If using both Z motors with only one driver is not an acceptable solution, you will need at least a Duex 2 (this will give you 2 additional drivers along with some other stuff)
check it out here
Alternatively you could connect a single (or more) external stepper driver.
click here if you want to learn how

JV

@simonjb as long as you entered your the height of your printer corectly, the firmware imits will work.
The only problem that might arise is, when the printer loses steps during printing, but I'm not sure what could cause something like that on your Z-Axis.
If you want to be extra safe, put G0 Z295 or G0 Z290 in your end-gcode.
If you want to be extra extra safe define your Z-height as 290/295 in the firmware.
You will lose 10/5mm of usable printvolume your printer wont be able to use, but you'd have that extra peace of mind

@dc42
Awesome!
I'll test it once you release 2.03RC3