Topics created by EducatingSavvas

headache.jpg 😉

@rjenkinsgb that works, thanks for that - so I'll have to write the IP addresses in the student workflow. Hopefully won't confuse them too much. @jay_s_uk Not bad, just busy as usual. It's strange but writing http://anything.local accesses the web controls.

@educatingsavvas could be the case. I think the last job I ran was with beta 4 or 5

@educatingsavvas not at the moment. i believe this is due to be looked at in 3.5

@educatingsavvas said in M291 S3 not blocking when called with M98:

WiFi firmware version 1.23

Not really related, but your wifi server is a bit out of date. How have you been updating the firmware? Regardless, you should be able to update just the wifi firmware by uploading the latest version.

https://github.com/Duet3D/RepRapFirmware/releases/download/3.3/DuetWiFiServer.bin

@jay_s_uk Hi Jay - got it working but have a new problem with long pauses during resumes now. That was actually something I raised a while ago but was not picked up. https://forum.duet3d.com/topic/26582/rrf-3-4-0beta7-resume-bug?_=1642609963044

@dc42 Morning, I'm using a Duet 2 Wifi.

@alex-cr Hi Alex - I've used triggers but since going from RRF3.3 to RRF3.4beta7 there seems to be an issue with resuming. I think something as safety critical as an interlock should be defined by it's own gcode. It's just a suggestion, as some workflows seems to be overlooked.

For example using M291 S3 command in a start.g file doesn't cancel the job about to commence if the message is cancelled.

This seems like a better case to use a conditional check either for an object model state or a variable that gets set.

@phaedrux Thanks again for that pointers. I'm going to have to investigate this in the new year now. I'll try commenting out the M574 commands from the config file and placing individual lines into each homing file. It sounds like I should also include M915 in the config file but sensorless homing individual axis has worked without it.

The only other thing I can imagine may be causing an issue is I have the following line in my config file...

M584 X0 Y1:4 Z2 V4 P3; Apply custom drive mapping, P3 hides V(Y2) axis. ***

and I should remove V4 from that as it's not needed. Thanks again, and hope you have a good xmas break. Savvas

@o_lampe said in Different idle factors for M906 motor currents?:

@deckingman
sure, but would UV switch to idle mode (because I switched to another tool) while XY are moving? I can set the current in the toolchanging macros, but what if it also switches to 30% of the already reduced current?

As I understand it (but I could be wrong), UV will not switch to idle mode while XY are moving because the timer starts when there are no moves (on any gantry). I believe that idle hold is switched off for all motors as soon as any one is commanded to move (but again, I could be wrong). I guess it would be easy enough to check. Set idle hold to low current so that you can easily move a gantry when it is enabled, wait for it to kick in, then do a (say ) G1 Zn and see if you can move XY or UV (i.e do they now have full current or reduced current?).

https://github.com/Duet3D/RepRapFirmware/issues/new/choose

Perhaps consider also making a feature request on github?

@cosmowave Yes that works - perfect. 🙂

@educatingsavvas I've not had chance to try them yet either as my CNC is in bits. Hopefully soon I'll be back to tweaking my settings

@educatingsavvas you can also use this one https://uk.rs-online.com/web/p/mosfets/8259364/?sra=pmpn. That's the one we use for the bed heater mosfet, which needs a higher specification than the other heater mosfets. However:

and checking between gate and drain turns the LED for E2 turns on

That suggests to me that the mosfet is OK but either the output pin of the 74HCT02 is not connected, or the gate series resistor is not connected.

@educatingsavvas See https://duet3d.dozuki.com/Wiki/GCode_Meta_Commands#Section_Variables. Note that you need v3.3(-RC3) or newer if you are using your board in SBC mode.

@dc42 The enable inputs can be set to accept high, low or any type of inputs up to 24v, so I don't think these are the problem. While troubleshooting I've set these to accept any but my plans was to use a spare pin and M42 command in the tool number for additional failsafe. The adapter seems to be very versatile and the manual suggests quite a few ways to set up.

That said I'm still having problems that feel like grounding issues with the heat terminals on the duex - I am using PWM-1 for the laser and E3-E6 to control LED lights through the deomon.g file.

I wired the ground from pin 4 on the CNC adapter to the laser PSU ground - separate from the stepper PSU. I had my signal go to inverted TTL from the Duet PWM 1 header. The controller turns on as normal, and if I press the red arm button and close the external switch (which I leave normally open at start-up because I use a key) the arm LED turns on but the Laser LED just flickers briefly on and turns off. What I've noticed also on the duet is E3 and E4 lights are on when only E4 should be on at start up. Those along with E5 and E6 for used for LED's which signal machine state. The LED for heater 2 does not turn on - it seems the pin is being pulled down or drained to ground - but if I open the external switch on the cnc adapter the LED for E2 lights up. The seems like like a ground issue.

In any case I have received some additional troubleshooting guidance from Opt Lasers which I will go over on the weekend to identify if it is the laser head or adapter.

@EducatingSavvas related github issue:
https://github.com/Duet3D/RepRapFirmware/issues/537

EducatingSavvas created this issue in Duet3D/RepRapFirmware open [FeatureRequest]: Buffering Commands Safety Concerns #537