Best posts made by SupraGuy

I also do lots of other DIY electronics.

For audio amplifiers, and circuits where ground loops can cause some very undesirable things, particularly since there are a lot of places that can cause ground loops in audio equipment, it seems to be pretty standard practice to have an isolator between the DC ground and actual earth.

I have built a bunch of circuits from Eliott Sound Productions, pre-amplifiers, signal processors, and audio amplifiers. I made quite the sound system with his circuits.

In this schematic, you can see in the bottom, the parts used for the loop isolator. D1, D2, R1 and C1 are all in parallel providing a nominal break between earth and the DC ground. This one is for a dual amplifier supply, but shows that the AC earth should have at least a modicum of isolation from the DC ground. This is also true for single-rail supplies. Failing to do this can result in audible noise in audio circuits.

If you omit D1 and D2, this will still work as an isolator, however should a large potential build up, you might end up burning R1, which would normally be a 0.25W device. The diodes protect R1 by acting as a dead short for voltages above the Vf of the diode, typically a bit under a half volt.

The Meanwell diagram seems to only use C1. This is probably adequate if there is no electrical fault elsewhere, but we're doing this in case there IS a fault elsewhere.

Re-sizable controls. I might want a fairly control dense screen on my RPi 480X320 screen with a trackball, or I might want only a few key buttons if I'm using the same in a 5" touchscreen. Kind of different if I'm displaying on a 4k monitor.

I commonly use an RPi with a 1280X720 7" screen, my phone (5" 1080X1920 or 1920X1080 screen) or my media PC (40" 4k screen) with DWC now.

The phone is the most maddening, but the one that I am most likely to use for babystepping adjustments.

For me thought the biggest thing that I'd like to see is user levels. One level where you can print pre-stored files, one level where you can upload macros and files, and one where you can update firmware, and main configuration. (Let the kids print another object, daily use, and admin privs.) Yeah, I'm aware that with "Gcode everywhere" uploading a Gcode file can do whatever mucking with the configuration files can do, but at least it can be reset with a power down. (I'm a network admin for my day job. Proper user sandboxing is something that I like.)

No way I'm granting Internet access to any device that doesn't need it.

My Duet can talk to my LAN, but cannot talk to the Internet. Even if you can somehow convince something else on my LAN to talk to the Duet for you, the Duet isn't going to talk to the Internet. My Raspberry Pi running its RetroPi distro can't talk to the Internet directly. I download images and updates to a more secure server on the LAN, then download to the Pi from there.

I don't need access to my 3D printer from the Internet. I don't think I'd even leave it powered on while I'm not there. Maybe (but probably not) if I were leaving the house to go somewhere and finish a 3D model which I wanted to start printing before I come home... But then what to do if the first layer messes up? I suppose that I can put a webcam on the printer to see, and abort the print, but it's not like I can scrape off the ruined layer, re-prepare the bed and start again. It would be a one-shot "works or doesn't" attempt, and something rare enough that I can't see setting up for it. Besides, there are plenty of secure enough ways to remote control a PC with reasonable security, which will then be able to access other machines on the LAN.

I figured that it's only a matter of time before things like this become hacker targets.

I'm not concerned about someone stealing my gcode files, and I believe that I have reasonable enough safeguards in place to keep someone from starting a fire with my 3D printer.

Test that the wires go where you think that they do. Test for continuity with it disconnected from the Duet. You should have continuity between the black and red wires, and between the blue and green wires, but not between any other pairs.

Check that you have the jumpers on the second Z motor connector. If that is open, your motor will not move.

You have the choice of Vin (Whatever your main power supply is) or 5V as selected by a jumper on-board. Alternately, if you have another power supply voltage (Say, your Vin is 24V, and you have a 12V converter) you can connect that to the jumper instead and power your fans that way.

Most people select fans to match their main power supply.

I've moved all of my stuff (Except for some half-baked things that weren't any good) onto Prusaprinters.org myself. Probably moves some of the crap over, too, honestly.

I've recently become a little more serious about my CAD development, so hopefully better things coming.

Okay, so looking at your printer, it appears that the bed moves in the Y axis.

Since you have a Bowden extruder, the X axis is going to be much lighter than the heavier bed, so increasing the moving mass in the Y axis is going to slow down your printing, in that you will need to use lower values for accel in the Y axis with the heavier mass, all else equal.

However, if you are upgrading from 12V to 24V, you might find that your motors will deal with it better overall, though there will still be some ringing, just as a part of the nature of the drive belts. Well, any drive system, really.

I added a couple of pieces of aluminum bar to my Y axis as a part of getting my Piezo Andromeda sensors set up. Maybe a couple hundred grams, I didn't weigh them specifically. It didn't seem to make a noticeable difference in the ringing that I get in the Y axis, but I also print somewhat slowly, since the leadscrew drive configuration that I use doesn't lend itself to very high speed moves. I hardly ever have anything above about 75mm/s, and perimeters are never over about 50mm/s.

How much does your mirror weigh? If you can print without it on the aluminum, that's probably a better solution anyway. Glass is terrible for thermal properties. I use it myself because I like the super-smooth first layer, but I'm looking at solutions to print without it, since almost everything that I print can tolerate a slightly rougher surface texture, and even the 2mm glass that I'm using has its weight to consider.

In your position, I would probably use the 5mm plate, and do away with the glass. Use a PEI sheet or similar instead, and you'll have more even heating, and probably better adhesion with most prints. It's likely that you'll be much happier with the overall result, even if you have to slow down your Y accel by a few percentage points.

From your post, I'm assuming that you have 2 Z stepper motors, and that the printer worked, but you (temporarily) removed one motor, and when you reinstalled it, you're getting inconsistent results.

Is it consistent? Is it always the same motor that is lower at the end of the print, or does it go back and forth?

I'm sure that you checked, but I'll ask for completeness. Are you certain that you didn't get anything stuck in the motor mount, like plastic debris, or bits of leftover plastic skirt/brim? Are all the screws tight? Are the Z screw couplers tight and have you checked them for play?

I'd think that the most likely cuplrit would be a set screw that is allowing the motor to turn inside the coupler, or the coupler to turn without turning the screw. A very small amount would add up, particularly if you have fine-pitched screws. It's unlikely to be the control electronics, or the motor itself. I would think that a mechanical issue is the highest probability. (I just replaced my Z couplers, and had an issue where the threaded rod on one side would MOSTLY turn with the motor, buton high speed moves, or with sudden reversals like a short lift motion could get out of sync with the motor.)

I'd go over all of the screws, from motor mounts to couplers and make sure that they're tight. I'd go with both sides, just to be sure. Make sure that you can't turn the screws without the motors turning. With them powered on, you shouldn't be able to turn the screws at all.

@t3p3tony Sorry 'bout that. I "report to moderator" when I see one of those (But only once, even when there are 20.) On a forum this active, I'm probably not the only one, but the "I thought someone else would do it" factor applies, too. (I've been a forum moderator for other places before, I know how this sometimes works.)

Every once in a while the bots manage to sneak one past the mechanisms meant to keep them out. Sometimes the bot software gets better, sometimes they just get lucky. Whenever they do, it's always a fight like this. I'm almost certain that it's almost always SEO crap (Something like this one, where it seemed to be a website URL over and over again is almost certainly SEO.) and sometimes it's regular spam, trying to get users' attention.

Thanks for taking care if it!

You can specify a minimum of say -110mm and a maximum of 110mm (for example) in order to have the bed center be 0,0. Some people do this so that the same gcode will operate on multiple printers with different geometries or mechanisms.

I personally do not do this, since I use different materials and nozzle sizes, so I need to re-slice for different printers regardless.

In my case, I set it up so that 0,0 is the front right hand corner of the printable area, even though the printer mechanics can move the print head further. If memory serves, my minimums are -11mm X and -9mm Y. (Might be the other way around. My pause.g parks the print head at -5,-5.)

I can't see a way that the G29 command can abort the print job, given that there aren't any conditionals in gcode, unless it forces some kind of fault condition that shuts down the firmware requiring a reboot. Until such time as gcode has an "if" statement, but I don't see that coming soon.

I don't know that I'd want to average all values either. If I get one false trigger at Z=5, then 9 good triggers at -0.2 < Z < 0.2 my average will be about 0.5 too high. Personally, I'd rather that have a 0 entry in heightmap.csv for a "didn't probe there." which ought to cause the firmware to average the points that surround the bad probe point. Of course it depends on how many times you get a bad value from your Z probe. If yours is prone to false triggering (Which is the reason for multiple probes,or so I thought) then you could get some really wild average values.

So my preference would be to use a median value, rather than a mean, under the hopes that there would still be more good readings than false triggers.

Well, that's vague...

Assuming that you want to be able to tell an external Arduino when something happens, it will kind of depend on what events you want to signal, as well as what I/O you want to talk to the duet about.

I'm looking at doing a few external things with an Arduino myself, like adding some "on printer" controls (Baby stepping, possible direct axis control, homing, manual mesh leveling) probably with something like a RepRapDiscount 2004 controller (Since I have 2 or 3).

In my case, I'm pretty sure that the way that I'll do that communication is via the PanelDue port as serial communication, and configure the spare Arduino to send gcode over serial.

If you are doing that, I'm sure that you could insert gcode into the config.g file to send a "hello" message to the PanelDue port, which your other arduino could listen for and then begin whatever other code you want it to run. whether you could get sufficient communication this way I guess depends on what information you want your other arduino to monitor, and what kinds of things it needs to tell the Duet that it has managed. Some things will be easy enough to monitor over the serial line, other things might require a hardware trigger, though configuring the Duet to send such triggers might be a trick.

This is kind of what I was suggesting in the other post.

If you have 2 UARTS on your arduino, put it in the middle, but you shouldn't actually need to.

If you just grab the ground and the Duet's TX pin, you should be able to read the Duet's responses to the PanelDue's M408 queries without the need for any other operations.

If you want to make sure that there is no level loss, you COULD probably use an op-amp as a buffer, which could then also manage the level shift from 3.3V at the Duet's output to 5V for the Arduino's UART. The op-amp's input resistance can be plenty high enough to ensure that there is no signal loss to the PanelDue.

You should not need to connect to the Duet's RX pin. note that doing so may mess things up, since the PanelDue sends line numbers with its gcode polling of the Duet, and you'd possibly mess up the sequencing if you inject your own instructions/queries. If you're going to do your own polling, I'd strongly suggest that you look at an arduino with 2 UARTS and insert it completely between the two.

It seems that you're running the 2.02 firmware just fine. what you don't seem to have is a valid config.g file.

I would follow the guide for getting started (https://duet3d.dozuki.com/c/Getting_Started)

Specifically, set up at least network connectivity (https://duet3d.dozuki.com/Guide/1.)+Getting+Connected+to+your+Duet/7)

Once that's done, then you can go to the RRF configurator tool (Link in the first report.) to create a set of configuration files, which you can then upload using the web control over the network. So far it looks like you'\re connected to USB only power, with no Vin (power good: no)

If you don't want to connect to the network for whatever reason, you can unpack the configuration files onto the SD card in the /sys folder.

If it's getting worse that way, then you may have the motor drives reversed.

So the motor that you have at -15, 250 should be connected to drive 5, and the one at 1200, 250 should be connected to drive 6. I'd say try switchig the motor connections around and trying again.

I'm doing this (Single extruder, so I'm using drives 2 and 4 for my Z axis) and it works quite well.

Using an arduino to control a couple of LEDs is overkill, don't you think?

Maybe if you had a bunch of other functions that the Arduino was doing, that would be another matter, but for a simple red/blue LED switch, it's a little...

I'll usually watch the LED on-board, because that tells a story. If the heater LED is on, then I assume that the Duet wants the heater to be hotter than it is. When it turns off, it has reached temperature. Of course it will cycle on and off while it maintains temperature.

Personally, I'd probably be tempted to insert the Arduino between the Duet and the PanelDue, have it intercept the serial communication between the two (Panel Due sends M408 S4, Duet responds with a JSON dataset, which includes things like the bed and heater temperature, then just pass on the information. you internally parse the JSON dataset, and do what you want with the information. your Arduino will need two UARTS to do this, one to talk to the Duet and another to talk to the PanelDue. It should appear invisible to both units, taking all data from the one and passing it to the other. Maybe you can use a single UART to tie it in in parallel, only monitoring the duet's output. you'll need to do some creative guessing to try figuring out what the PanelDue is asking for, but you can probably look for the JSON pattern that signifies the M408 response from the PanelDue and ignore other input.

This will give your Arduino a lot of information, like temperature, tool coordinates, homed status. (An example of an M408 S4 response:

{"status":"O","coords":{"axesHomed":[0,0,0],"xyz":[0.000,0.000,0.000],"machine":[0.000,0.000,0.000],"extr":[0.0]},"speeds":{"requested":0.0,"top":0.0},"currentTool":-1,"params":{"atxPower":0,"fanPercent":[30,100,100,0,0,0,0,0,0],"speedFactor":100.0,"extrFactors":[100.0],"babystep":0.000},"sensors":{"probeValue":0,"fanRPM":0},"temps":{"bed":{"current":2000.0,"active":0.0,"state":0,"heater":0},"current":[2000.0,2000.0,2000.0,2000.0,2000.0,2000.0,2000.0,2000.0],"state":[0,0,0,0,0,0,0,0],"tools":{"active":[[0.0]],"standby":[[0.0]]},"extra":[{"name":"MCU","temp":37.3}]},"time":313.0,"currentLayer":0,"currentLayerTime":0.0,"extrRaw":[0.0],"fractionPrinted":0.0,"filePosition":0,"firstLayerDuration":0.0,"firstLayerHeight":0.00,"printDuration":0.0,"warmUpDuration":0.0,"timesLeft":{"file":0.0,"filament":0.0,"layer":0.0}}

So some other things that you can grab from this are things like the CPU temperature (Mine is apparently about 37 deg C right now), which you can use to control a cooling fan. This Duet is reporting 2000 deg for all heaters because there are no sensors actually connected to it. I'm actually using it developing/testing an interface using the PanelDue port to talk to a Raspberry Pi which will do most of the things that the PanelDue can do, plus some additional things that I want it to do (Like control a cooling fan.)

Note that this will not only give you the current temperature, but also the active and standby temperatures, the current selected tool, plus the state which tells you what the Duet is supposedly aiming for. You can then have 3 lights (Blue for current tool temperature + 3 < active/standby temperature, green for current tool temperature within 3 degrees of target, red for current tool temperature > target temperature + 3) Or whatever else you can imagine.

I think that this is probably the best solution to get the information that you want. You'll need to be sure to be constantly passing the information between the two boards back and forth to each other, and your Arduino may need level shifting (Depending on which Arduino you use) to get 3.3V on the UART instead of 5V, but the end result will get you the information that you want. (You won't even have to ask for the information, since the PanelDue will do it for you.)

@danal said in Connecting PanelDue and Arduino to one serial port:

Not needed for buffering the input. The RX in on the Arduino is exactly the same as that OpAmp input. Maybe even less impedance...

Absolutely not needed, unless for 3.3 to 5, and I'd use a digital level shifter for that, not an analogue op amp.

@Danal That's my own bias showing up. I have a box full of dual and quad op-amps ready to hand, so I tend to use them as level shifters, also the pile of arduinos that I have that I might use for a project like this are all 5V logic. I'm pretty sure that I could solder up a 3.3V to 5V TL072 buffer on breadboard in my sleep. (Or 5V to 12V, since I've done lots of those for Arduino to PC RS232) Come to think of it, I probably already have a few already in the box with the op amps.

You know what they say, if the tool that you have is a hammer, make every problem look like a nail.

I 100% agree that you shouldn't need a dual UART Arduino, but I probably would want to do more with an arduino than just control some lights, if it were me. I have my own project underway, sort of concurrently developing with a raspberry pi and an arduino to add some hardware buttons to the printer. I'm not sure which SBC I'm going to choose in the end to add 6-8 buttons and a few display functions. Probably not anything that the PanelDue won't do, but since I already have the hardware, I might as well.

When does it do this?

The G code file homeall.g gives the instructions to the printer in order to home all of the axes, X, Y and Z.

homex.g homes the X axis only. homey.g homes the Y axis only. homez.g homes the Z axis only.

At the end of print jobs, you will often see something like

G28 X Y

G28 is the home command, and the X and Y are the flags to tell it to only home those axes. By convention we tend to list them in alphabetical order (X, then Y, then Z) when we do that. It will then call the appropriate gcode file to home those axes.

It sounds though like you're using homeall.g, since you mention that it does X and Y at the same time.

My homeall.g file looks like this:

; homeall.g
; called to home all axes
;
; generated by RepRapFirmware Configuration Tool on Thu Aug 30 2018 14:11:29 GMT-0600 (Mountain Daylight Time)
G91                   ; relative positioning
G1 Z5 F6000 S2        ; lift Z relative to current position
G1 S1 X245 Y280 F3000 ; move quickly to X and Y axis endstops and stop there (first pass)
G1 X-5 Y-5 F6000      ; go back a few mm
G1 S1 X225 Y280 F300  ; move slowly to X and Y axis endstops once more (second pass)
G90                   ; absolute positioning

In order to change it so that it homes Y first, then homes X afterwards:

; homeall.g
; called to home all axes
;
G91                   ; relative positioning
G1 Z5 F6000 S2        ; lift Z relative to current position
G1 S1 Y280 F3000      ; move quickly to Y axis endstop and stop there (first pass)
G1 Y-5 F6000          ; go back a few mm
G1 S1 Y280 F300       ; move slowly to Y axis endstop once more (second pass)
G1 S1 X245 F3000      ; move quickly to X axis endstop and stop there (first pass)
G1 X-5 F6000          ; go back a few mm
G1 S1 X225 F300       ; move slowly to X axis endstop once more (second pass)
G90                   ; absolute positioning

Most Cartesian machines use the front left of the bed as the origin. I had my original I3 configured so that the endstops were at the minimums (Back right) which worked, though my prints came out 180 degree rotated from what Pronterface was showing me. (Never bothered me enough to reconfigure Marlin to use the Max endstops instead of the Min ones though.)

Mirror image prints would be a problem, and I'd probably recommend that you swap one of the axes around. It would be best if you did it so that the print appears on your print bed the way that it looks on your slicer. like I said, my first printer had it the other way around.

Using the Duet electronics, it's not hard to do at all, it can all be done in software.

change:

M569 P2 S1 ; drive 2 goes forwards

to

M569 P2 S0 ; drive 2 goes backwards

Then change homey.g and homeall.g to move in the opposite direction, since the Duet doesn't differentiate between and endstop being a maximum or a minimum.

If it works better to reverse the X axis instead, it's pretty much the same change, just change drive 1 instead. Change one or the other, so that you get the results on the print bed the correct orientation.

Hmmm. You said mirror image, so it might actually be the X axis that you want to reverse...

If it's the series or parallel wiring that you don't understand, this is going to be difficult for you to do well.

As stated, you only use one driver. For parallel wiring, each motor will only get half of the current, but see full voltage that goes through your driver. For series wiring, each motor will get the full current, but see half of the voltage. The drivers limit voltage in order to regulate current, so this is okay, so long as your driver has enough voltage going to it to have spare.

RAMPS boards, are typically used with 12V, and so they wire two Z motors in parallel, in order to maximize the avaialable voltage. The Duet by default operates those motors in series, as it is better designed to take advantage of 24V power input, though it can also operate at 12V.

The outputs from your stepper driver determine which it is. Call the motors Z1 and Z2. each of these has 2 coils, A and B, each coil has 2 terminals, 1 and 2.

Your stepper driver has 4 outputs, A2(out) A1(out) B1(out) B2(out) named for the coils and terminals.

In parallel wiring:
A2(out) goes to both Z1A2 and Z2A2
A1(out) goes to both Z1A1 and Z2A1
B1(out) goes to both Z1B1 and Z2B1
B2(out) goes to both Z1B2 and Z2B2

In this way, whatever the driver puts out gets split between both motors

In series wiring:
A2(out) goes to Z1A2
Z1A1 goes to Z2A2
Z2A1 goes to A1(out)
B1(out) goes to Z1B1
Z1B2 goes to Z2B1
Z1B2 goes to B2(out)

If there is no motor connected to the Z2 connector, then you must jumper Z2A2/Z2A1 and Z2B1/Z2B2 or else the whole thing becomes an open circuit and the other motor will not turn at all. (You will get the exact same situation by swapping the jumpers to the Z1 connector and the motor to the Z2 connector.)

I was going to do up a diagram, but I'm not sure that what I could do quickly would be any clearer.

It is also possible to use multiple stepper drivers with each connected to an individual Z motor, but in this case, you would use a different step/direction channel. Unless you are looking to run stepper motors that require more power, and a single driver cannot handle more than one motor's voltage/current needs, in which case, you might want to reconsider component selection. The duet firmware can deal with multiple motors for any given axis.