Topics created by 3DPotter

@3DPotter as Jay says, you would need to compile your own firmware to do that. The pins used are defined in file src/Config/Pins_DuetNG.h. A further possible complication is that the current code assumes that all step pins are on Port D, so if you swap a step pin with another pin that is not on Port D then a code change would be needed too.

@droftarts
Probed a bunch of random places on the board where the 3.3v and 5v lines are at. They were all the same and were all about 5.5v and 3.5v

The thing is the board overheats the same, even when its only being powered over USB...... must be a damaged MCU.

Thanks. Works great. Was not working for me as I was on version 3.1
Works great on 3.5.1

Video of it working: https://www.youtube.com/watch?v=hMWtKxBUGBE

Thanks. Works great. Was not working for me as I was on version 3.1
Works great on 3.5.1

@3DPotter it looks to me that the amplifier you are using has an output slew rate too low to handle the higher frequencies well.

@dc42 We are connecting it via the expansion slot pins. M569 P9 S1 R0 T4. The E6 pin: Pin 25 and Pin 2

There may have been a word/grammar miscommunication. When I said PWM above, I was referring to the STEP signal.

We are not using any fan or heater connectors on the board currently.

Perhaps it is the amplitude of the pulses that needs to be greater? Is there a way to do this? I may be wildly not correct for doing this, but the voltage output using a multi-meter always measures 0.6v from Pin 25 to 2 when an extruder move command is sent. ~0v during idle. On the cheap pulse generator device, the output is always 6.5v when in use. (I do not have an oscilloscope).

Screenshot_70.png
(PS: sorry for the 1 month delay, other project got in the way).

The 6XD may be the best option for external drivers.

The mini5+ may be best for the normal stepper drivers and you can add a 1XD board for each external stepper

https://docs.duet3d.com/en/Duet3D_hardware/Hardware_overview

What PID tuning command are you using?
What fault do you get?
What firmware are you running?
What kind of heater is it?
What is it heating?

Thank you o_lampe. I will give that a whirl and report back!

Probably a question for the YAT forum: https://sourceforge.net/p/y-a-terminal/discussion/

@3dpotter

FOUND SOLUTION.

After connection is established in BOSSA, you then plug in the reset jumper for 1 second. And then push the update. Update installs normally, but then after board is rebooted, diag light is off and board shows up correctly in device manager/yat.

This means for unresponsive boards you have to leave the reset pin in until you can connect with BOSSA, and then take it out, reconnect/relaunch again, and then do the step I listed above. This just saved like 10+ boards. woot.

@zapta said in Max amperage for motor drivers?:

I wonder what is the motivation for this requirement. Can you explain?

I'm guessing he just wants a lot of power considering the weight of the clay building up on the spinning table.

I bet it's the Simplify3D thing.

Time to move to PrusaSlicer! 🙂

Thank you. I swear I thought I had tried that. Problem fixed.

@dc42 said in Filename too long error:

Is the user running Kapersky AV? See my previous response.

They were not. When I inquired what anti virus software they were using their response was "On mac, I don't use antivirus."

😑

Sorry, I don't have that data of what caused the issue. I am just assuming that since your problem from what you described as a service/anti-virus on the computer is sending requests to the board and overloads it over time, is the same thing that happened here, but we don't know what service it is.

They are in another country and there is a language barrier.

They resolved their issue by using a different computer.

@dc42
It was an issue a long time ago, but was fixed with an unknown firmware update. Some path movements were extremely odd with older versions, things like disregarding motor speed in order to maintain head speed at all costs. Or arm movement take the longest way around the machine in order to reach a position.

The major movement problems were corrected in update 2.03RC1, but not all of them. Also, this update did not obey minimum travel distance correctly, M208 S1, and did not always take the most efficient paths.

With update 2.04RC1, it seemed like everything was fixed for us and things went great. All pathing was taking the most efficient routes (better than before), all limits were being followed, and no machine crashing. But it must have slipped under us, as when we started to print more complex g-code files we would get that Error: G0/G1: target position not reachable from current position. We do not receive this error on version 2.03RC1, and the print runs fine.

Currently we are running on 2.03RC1, but as I mentioned some safety feature are not working and it is easier to crash the machine into itself.

We want the minimum limit M208 S1 to be obeyed as well as have the best pathing. If you would like I can go through the updates to see what problems occur on them and provide documentation/files with videos of how the machine is operating.

This is a bit of a hack but it should work.

Set retraction parameters to a set value. Say 2mm retract and unretract.

Then use a post processing script REPLACE command to replace it with the servo commands you need. Match this command to your actual retract command output from S3D

{REPLACE "G1 E-2.0000 F1800" "M280 P3 S0 I1"}
{REPLACE "G1 E2.0000 F1800" "M280 P3 S80 I1"}

Or if you need to wait for it to close you could do something like this:

{REPLACE "G1 E-2.000 F1800" "M280 P3 S0 I1 ; close servo\nG4 P500 ; wait for servo to close"}
{REPLACE "G1 E2.000 F1800" "M280 P3 S80 I1 ; open servo\nG4 P500 ; wait for servo to open"}

the \n character will make a new line in case you need multiple lines like in the second examples.

Changing the M667 parameter to A-180:181 worked. Thank you.🙂

Figured it out and got it working, thank you. It was in the offset command.

That was it. Thank you.

Staring me right in the face.