Posts made by Maestro

@T3P3Tony I would suggest either removing or updating the 130mm dimension up the left side as well, as this dimension is in fact 129.5.

Splitting the proverbial hair, I know!

@marco_meier Those drives can use a 24v signal, however they will also accept 5v Step/Dir signals on the proper pins, so you can simply run 6XD 5v to CN1 pins 3 and 5, and Step- and Dir- to CN1 pins 4 and 6, respectively.

All you really need to concern yourself with voltage-wise is the 24v enable signal, which the Duet team has confirmed the 6XD CANNOT sink on the EN- pin. The enable circuit on my breakout board would do what you need, and you could easily coble something like that together without making the whole board. Really, any simple relay/electronic-switch style setup that allows you to trigger a 24v connection with the 5v-tolerant EN- pin from the 6XD will accomplish what you need.

Bit of a weird one here...

I printed a mounting plate for the 6XD a while back and found that it didn't quite fit right. Recently I made a new one, built in assembly from the STEP on GitHub, and it fit perfectly. That got me curious.

My original part was made from the physical dimension drawing on the 6XD Hardware Overview page. This drawing indicates a 5mm offset from the board edges for the mounting holes; hole coordinates (5,5), (5,135), (110,5), (110,135).

However, based on the CAD files on Github, (both v1.0 and v1.01) and my real-life genuine Duet 6XD v1.01, the mounting hole near the VLC fuses actually has a 5.5mm offset from the edges; it does not match the other holes, and the holes do not form a rectangle, as this hole is at (5.5,134.5).

The dimension drawing on the overview page is for v0.1 and v1.0, and I have v1.01. However, the STEP for v1.0 also has this asymmetric hole, so it does not seem to be the case that this is just an oddity in v1.01 (the only board I can physically measure), and the dimensional drawings are accurate for v0.1 and 1.0; at the very least, the drawing and the CAD for v1.0 are discrepant.

So, it seems likely that the original error here is in the CAD, as there doesn't seem to be any reason to asymmetrically crowd a perimeter hole into component space. However, the physical boards exist, so at this point the relevant error is in the dimensional documentation, which does not indicate real-world hole-spacing.

@Amagatth Ok, good luck. Sorry I interfered.

@Amagatth Yes, you can certainly move to a 12/24volt with a relay/mosfet. I would suggest making things very simple for yourself first and just jumping the drive's enable pins from 12/24v to ground (NOT going through the enable pin on 1XD) and see if that activates the drive as expected. If it does, then you know what you have to do to finish the setup. If it doesn't, you have a bigger problem.

Generally, if you already know from the jump that you are going against a manual specification, that would be a good place to start a troubleshooting request! Rather than someone else considering possibilities, going and looking it up, and then you basically saying "Yeah, I know".

@Amagatth According to the T6 manual linked to in that other thread, the enable signal for that driver is intended to be driven at 12-24v.

As far as troubleshooting goes, that is the obvious starting point. The fact that someone else says they ran it at 5v enable doesn't change that, and doesn't mean it's reliable. You might still have something else wrong too, but at the very least you're supplying it only 42% of its rated minimum, so that's one possible hurdle to check off the list before banging your head against a wall.

In terms of wiring, you are not using the terminology of the manual. If you think it could be a wiring problem, I'd suggest referring very explicitly to how you are interfacing the 1XD to the pins AS LABELED in the manual (pages 16, 17), so that everyone is on the same page. According to the manual, I would say you should be connecting to CN2-Pin1 (12-24v) and CN2-Pin2 (ground) to enable. Though, this is configurable; your servo-on command could potentially be mapped to a different input.

@Amagatth It is not clear from your post what connections you are making. Also, not clear what servo you are connecting to; a leadshine EL6-series? Which drive?

Whatever it is, do you have a wiring manual for it? Link? You will need to provide more details on the servo inputs and how you are connecting them to your 1XD.

Also, I would say there's a decent chance that the enable signal is 24v or maybe 12v, not 5v. But don't go zapping IOs with 24v until you confirm in your manual.

@Bad-Joker Whether a pelt can do what you need it to do without a fan is not a simple question that someone can confidently give you a yes/no answer on.

If you are allowing your sensor to hit 80C and your chamber to be 110C, your first thought might be that you need a peltier that creates a 30C difference. That is not the case; you need a pelt that will sustain a higher temperature difference, because if the hotside of the pelt/heatsink is at 110C, it is not releasing any heat to the chamber. I.e., your hotside must be higher than chamber temperature. Additionally, the pelt itself is a heater to the extent of it's inefficiency, which will also vary with temperature and temperature difference. The balance will be determined by the °C/W rating of your heatsink, which varies heatsink-to-heatsink, as well as with airflow. So, you are chasing a multivariate equilibrium point, and the answer is therefore "maybe, maybe not."

Another option would be to put the sensor on a waterblock and watercool it, in which case the answer to whether it is cool enough will almost definitely be "yes."

@lazy_mosquito said in how to enable out6 on 6xd for M569.7 command for brake:

when i later use the command M569.7 P0.0, it seems it doesn't do anything on port out6.

@lazy_mosquito I could be wrong about this, as I haven't used the brake function, however I would expect the brake output level to change when you run M17/M18, not when you run M569.7 again.

@maor3degem-co-il
I'm not sure what you mean by "the motor doesn't move 1/16 cycles than the other"? Irrespective of whatever values are read from firmware or anywhere else, that first video you loaded shows one motor moving 1/16 the speed of the other, at least within the resolution of the video to quantify.

Even it if is not possible to deliberately set different microstepping for 2 motors on the same axis in the firmware, that doesn't negate @droftarts's point that the drivers themselves could potentially decide that they've been given a different value due to noisy instruction sets.

@maor3degem-co-il

Any macros being called during the print? Anything running in daemon.g?

In your first post's video the right-hand motor looks to be turning 16x faster than the left, so, that's no random number. Wonder if code is being called somewhere that is changing your microstepping or steps/mm?

@AndrewStaines I'm afraid the 6HC is not designed for this application, and does not have provisions to drive step/dir outputs from the mainboard; with the 6HC this is only supported via an expansion board such as the 1XD.

As far as mainboards, the 6XD board is better suited to driving servos such as yours, and the setup for it would be reasonably straightforward, based on your diagram above. There would still be some things you need to account for, ones that immediately jump out being the 6XD's (or 1XD's) 5V step/dir outputs and your drive's 3.3V input, as well as needing to sink a 24v signal via enable pins (which they cannot directly).

Here is a Github repository for a breakout board I made to go between the 6XD and a pair of Yaskawa servos, which have drives very similar in overall setup to yours. Your drives will probably require some slight differences in spots, but this might get you started, especially the schematic.

I can't be confident without a close look at your drivers' manual, but based just on the schematic you provided, your bare minimum connections for functionality will be your CN1 pins 39, 37, 43, 41, 11, and 9, which will give you enable (I assume "SON" is "servo on") and step (Pulse) and direction (Sign). All of these have equivalents on my breakout board, with the same issues to be solved, though you need more information on your sign/pulse circuits to determine the proper resistor to bring you to 3.3V.

@Tinchus I have NOT tried this, so, purely theoretical, but if your filament sensor is configured I think something like the following in your loading macro at whatever point you want to check status would give you what you want:

if sensors.filamentMonitors[0].filamentPresent = true
  M-do-a-thing
  G-and-another-thing

@sbNielsen Have you looked for this vibration when using the web control at a wide variety of speeds? That's a big gantry; you may have some resonances leading to vibration; the variations in speeds during a print would make encountering these much more likely than inputting one particular speed for a DWC-called move. Does the vibration occur w/both X and Y moves?

Assuming you're running steppers, "basic tones, sort of melodic" is probably not a concern and may not be related to the vibration at all; the sound is to be expected during a print where speeds are varying all over the place and the driver/motor combo is not entirely quiet.

@Cj110109 Hello, Chris. As far as electronics setup goes, I don't really think there are any major nuggets I can give you, though I'd be happy to address any specific question. Once you abandon the original Creatbot toolboard abomination, your choices really aren't limited in any way.  By which I mean, it no longer matters--electronically--that you are building an F430.  As far as firmware and board ability go, you're just building a large, chamber-heated printer, so any resources towards that end will be valid for you.  I originally went Duet 2, but very quickly switched to a Duet 3.  If you're going the Klipper route, as you mention, there are plenty of resources out there for setup with that.  My own experience is with the Duet ecosystem, and that's primarily what you'll find discussion of on these forums. You say you already have a mainboard; I would suggest making a list of all the connections you need, and then going through one by one and learning how to connect them to your board.  There is variation out there on mainboard specs; your best bet is probably to find a forum that has a lot of activity relating to yours, because you can't assume that voltage/current tolerances, pull-up/pull-down state, etc. on one board's port will be the same as another's.

In relation to your project on a non-electrical note; I would never discourage someone from a project like this if it's something they just want to do for enjoyment or it's the resource they have.  However, I would just warn you; after many chamber temperature cycles between ~95C and ambient over the last several years, the welds in my F430's box frame have cracked in places, and splits are evident through the paint as sheetmetal starts moving around.  With certain motions it makes a clicking sound from something moving in the frame itself.
So, it does the job I modified if for; it prints large, good quality polycarbonate prints without warping/delamination.  However, it wasn't originally designed for it, and the process seems to be beating it to death slowly. I could fire up the TIG and patch it up, but I'd still be left with a sheetmetal box with limited potential. I'm working on the CAD for a new high-temp machine, and after serving as the bootstrapper starting point for it, this one is going to end up retired.

@Dizzwold I think this is a much-improved configuration, and nothing jumps out to me as problematic. As you've probably worked out, the only energized wire while things are off would be the solid-red line, which is a huge reduction in energized points compared to the last setup.

@Dizzwold said in Wiring Check, pre Tronxy X5SA Pro Overhaul:

Was this comment due to that I hadn't documented the Earthing to the Bed, Bed Frame and Printer Frame/That my mains circuit feeding my printer room/workshop is on it's own individual circuit, fused and RCD protected, or is there something else I need to consider here?

Yes, RCD circuit protection adresses this concern. The issue was that with the bed always energized--and no mention of ground-fault protection--a short at the bed would leave the bed both electrically dangerous and potentially still functionally "on" as a heater. This is because the load wire doesn't care one bit whether it closes connection to neutral or to ground, and your original config severed connections to neutral, but ground is still there to potentially connect to if things go physically awry (i.e. melt). A ground-fault interrupt can make the distinction of current passing through ground versus neutral and should trip to when a circuit closes to ground, so you would no longer expect a short-circuit to the bed to remain live.

@dc42 I did some quick tests and see what you indicate. With 4+ drive alarms closed at startup, all drives are treated as NC. In the middle case of 3-closed 3-open, it prefers NC, and applies NC to all drives.

Not to pile on, but an additional use case for logic selection is mis-matched drivers. I'm currently bench-testing with two NC-alarm drivers, but the final machine will have an additional four external drives. These drives haven't been selected yet, but they definitely won't match the first two, and could end up being NO-alarms. A global logic selection would at least allow selection of which drives you want the alarms to work straightforwardly on. A per-driver selection would be configuration nirvana!

@dc42 I did also test with drivers already powered first, but I only had two drivers connected, so based on this majority-rules approach it wouldn't have decided on NC configuration anyway.

I'll test later and confirm whether I get the response you expect. Either way, I do think the ability to set this logic would be a significant improvement, both for the delay in driver boot-up, and for the added assurance that the firmware will not make an incorrect assumption if something goes screwy at startup.

@curieos Apologies, made an unconscious assumption there.

Well, your alarm wiring is now working aside from the startup blip, which seems to indicate they're NO. Which matches with your multimeter readings. It doesn't seem you would have gotten the alarms to trigger in-use if they were NC. Unless you know something I don't about the firmware-side setup.

As far as how NC vs NO are supposed to work, it seems that the firmware currently knows nothing about NC/NO alarm status; I couldn't find anything about this in documentation. All the firmware knows is that if the error pin deviates from the jumper-pulled logic it's faulted. In both jumper positions, the driver must set the line to the opposite logic to trigger a fault. An NC alarm cannot directly set the line to something else when faulted, because then it's open-circuit and cannot affect the line; an NC alarm sets the line to something else when not faulted. The NC can be made to work with the current firmware (or my understanding of it), but the signal needs to be inverted in hardware.

It's not really a complicated circuit, but for some reason I'm finding it oddly brain-twisty. The possibility remains that I'm utterly wrong...

@dc42 I now believe there is a more general issue with NC alarm setup. I just did a little experimentation with my 6XD. I'm using drivers with NC alarms, single board, standalone mode, 3.4.6. Even with the drivers that are in use, it seems there is an issue with straightforward NC wiring.

Based on the documentation language for the error jumper:

• Jumper in the "top"/Pull Down position applies a pull down resistor to the driver fault signals - an external driver must set the line high to indicate a fault. A jumper in the "bottom"/Pull Up position applies a pull up resistor to the driver fault signals - an external driver must set the line low to indicate a fault

So, when the alarm outputs are open, the error pin will always go to the resistor-pulled logic, which means they will always go to the un-faulted position. So, it's always wrong for NC setups, which need to trigger fault when we go to the resistor-pulled logic. Seems we need a logic inversion ability in firmware? Perhaps this exists, but I couldn't find it in documentation (also in this recent thread @T3P3Tony said no go, at least in reference to M569).

Tested:
With external alarm linking error pin and ground, jumper set to pull-up position, I get a fault on startup (alarm circuit is closed). When I trip/open the alarm, there is no error event raised. When I reset/close the alarm, an error event is raised.

With external alarm linking error pin and 5v, jumper set to pull-down, I get the same behaviour; fault event on startup, no fault when the circuit opens during an alarm, fault event raised on alarm reset as the circuit closes again.

These tests are exactly as expected based on documentation. If we had the ability to invert interpretation of these signals in firmware then it seems NC alarms could work fine without any fancy wiring.