Posts made by clytle374

I didn't know if there was anything on the board to interfere with it.

Is using a thermocouple wired thru the smart effector do-able? Or even advisable?
Thanks
Cory

@droftarts

My internet in the building with the printer is a special kind of horrible, the main DSL hasn't been much better. I've spent the last 2 days working on the system. Fixed DSL, I think. Ran ethernet to building and removing the cheap wifi booster out here.

I've changed the wifi name and password in the config.g file on the duet. But it's still connecting to the old wifi. How do I get it to change over?
NEVERMIND: That was way harder than it should be.
Thanks
Cory

If I'm reading this properly I'm on the latest firmware.
Thanks
Cory

@droftarts

M122 output

M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 2.05 running on Duet WiFi 1.02 or later
Board ID: 08DGM-917DA-G4MSJ-6JKDA-3SN6N-KSRB9
Used output buffers: 6 of 24 (16 max)
=== RTOS ===
Static ram: 25712
Dynamic ram: 92584 of which 416 recycled
Exception stack ram used: 512
Never used ram: 11848
Tasks: NETWORK(ready,628) HEAT(blocked,1232) MAIN(running,3800) IDLE(ready,160)
Owned mutexes: WiFi(NETWORK)
=== Platform ===
Last reset 09:57:05 ago, cause: reset button or watchdog
Last software reset at 2019-12-30 07:03, reason: User, spinning module GCodes, available RAM 12088 bytes (slot 1)
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0441f000 BFAR 0xe000ed38 SP 0xffffffff Task 0x4e49414d
Error status: 12
Free file entries: 9
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 7.6ms, max retries 0
MCU temperature: min 42.3, current 42.6, max 42.9
Supply voltage: min 11.6, current 12.1, max 12.3, under voltage events: 0, over voltage events: 0, power good: yes
Driver 0: ok, SG min/max 0/395
Driver 1: ok, SG min/max 0/415
Driver 2: ok, SG min/max 0/414
Driver 3: ok, SG min/max not available
Driver 4: standstill, SG min/max not available
Date/time: 2020-01-08 12:35:31
Cache data hit count 4294967295
Slowest loop: 14.02ms; fastest: 0.07ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Move ===
Hiccups: 0, FreeDm: 156, MinFreeDm: 108, MaxWait: 0ms
Bed compensation in use: none, comp offset 0.000
=== DDARing ===
Scheduled moves: 724836, completed moves: 724801, StepErrors: 0, LaErrors: 0, Underruns: 0, 0
=== Heat ===
Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1
Heater 0 is on, I-accum = 0.1
Heater 1 is on, I-accum = 0.6
=== GCodes ===
Segments left: 1
Stack records: 1 allocated, 0 in use
Movement lock held by null
http is idle in state(s) 0
telnet is idle in state(s) 0
file is doing "G1 F3600.000" in state(s) 0
serial is idle in state(s) 0
aux is idle in state(s) 0
daemon is idle in state(s) 0
queue is idle in state(s) 0
autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 200.31ms; fastest: 0.08ms
Responder states: HTTP(0) HTTP(0) HTTP(1) HTTP(0) FTP(0) Telnet(0) Telnet(0)
HTTP sessions: 1 of 8
- WiFi -
Network state is running
WiFi module is connected to access point 
Failed messages: pending 0, notready 0, noresp 1
WiFi firmware version 1.23
WiFi MAC address cc:50:e3:0d:22:c1
WiFi Vcc 3.35, reset reason Turned on by main processor
WiFi flash size 4194304, free heap 22792
WiFi IP address 192.168.0.13
WiFi signal strength -51dBm, reconnections 0, sleep mode modem
Socket states: 0 0 2 0 0 0 0 0

I'm back online, here's the version info

RepRapFirmware for Duet 2 WiFi/Ethernet 2.05 (2019-12-13b1)
Duet WiFi Server Version: 1.23

Duet Web Control 2.0.4

Can I run M122 while printing?

It was updated to latest version end of November or December. It's been much better recently.

Can this be done through USB?

Wifi light is off, not blinking, just off

I thought this problem was gone after one of the recent updates, but it just returned about halfway through as 20 hour print.

What are the options to get the duet wifi to attempt to reconnect while printing.

Running Linux BTW

Thanks
Cory

I can confirm this is happening with latest stable firmware/web control
Cory

Much better results. I replaced the skates and it didn't really help. I tightened the belts as tight as I could using long needle nosed pliers under the idler support pried against the frame. Again, I've been shooting in the dark on proper belt tension since 4 years ago when I built it. That made a major improvement.

That didn't give good first layers. But provided a delta calibration that was accurate. Simply turning off bed mapping was the answer there since it is just as likely to be wrong as right at any particular point on the bed.

Trying to decide if I build a tool or mod then machine to get good control when adjusting the tension.

Thanks again for all the advice!
Cory

So I have some more information. Not sure that it helps with anything, but more information. I had ran a backlash routine before that dc42 had posted. But it was running in more in the center of the bed. I've been stuck thinking backlash was only in 'axis travel' and not somewhere else. That is poorly worded.

I decided to take a different approach after someone said it looked like one axis was causing it. I had assumed all 3 were, or I guess it could just be the rear tower as you don't see the problem there as much because of the probing pattern. So I wrote a program to probe at a radius of 100mm in line with each tower 4 times after an 30mm outward move then 4 after an 30mm inward move both inline with the tower. Here are my results.

12/2/2019, 1:42:41 AM: : G32 bed probe heights: -0.023 -0.017 -0.017 -0.017, mean -0.019, deviation from mean 0.003
12/2/2019, 1:43:13 AM: : G32 bed probe heights: -0.130 -0.136 -0.136 -0.136, mean -0.135, deviation from mean 0.003

12/2/2019, 1:43:46 AM: : G32 bed probe heights: 0.045 0.045 0.045 0.045, mean 0.045, deviation from mean 0.000
12/2/2019, 1:44:19 AM: : G32 bed probe heights: -0.111 -0.111 -0.111 -0.111, mean -0.111, deviation from mean 0.000

12/2/2019, 1:44:51 AM: : G32 bed probe heights: 0.040 0.040 0.040 0.040, mean 0.040, deviation from mean 0.000
12/2/2019, 1:45:24 AM: : G32 bed probe heights: -0.110 -0.117 -0.110 -0.110, mean -0.112, deviation from mean 0.003

So there it is. Now if I move up and down with an indicator at one point, I don't see even a quarter of that.

Looking over the machine again, I noticed movement in a skate. I went to snug a screw and the bearing journal post inside broke off. Found cracks in all of them. I had replaced them earlier this year and emailed seemecnc if I could just buy the shells. They sent me replacements at no charge! Great people!

So that could have been the problem, or not. I probably over tightened the screws. Going to replace them with 3/4" long instead of the 1/2" provided to keep from putting all the stress at the weakest point.

Hopefully that was the whole problem all along. I would think any other backlash would show up in my previous tests.
Thanks
Cory

No twist in my belts, I don't think there is room with the routing of them. Be too tight of a twist.

Wow that bed map is great. Linear bearings are great.

Thanks
Cory

@Danal said in Diagonal rod length on delta printer issues.:

I replaced the belts at some point a few months back, as "preventative" main. At that time I updated the bottom idlers. No detectable difference.

Thanks, helps for others to state that isn't the problem. Especially when I keep looking at the pattern and seeing 'belt teeth'

Thanks
Cory

@droftarts said in Diagonal rod length on delta printer issues.:

There's been a couple of other threads on the forum recently, with people with sawtooth bed maps like yours (see 1 and 2). The clue is that, when the bed is probed, the nozzle moves in different directions in X. So if there's anything causing the effector (or nozzle carriage in a Cartesian/CoreXY machine) to tilt, and especially when using a probe offset from the nozzle in X or Y, you'll get a high points in one direction, and low points in the other.

So it does rather seem like backlash, probably causing effector tilt, that effects the probed point, particularly as the motors change direction. As you've pretty much changed everything already, and this has consistently been a problem (to be fair, I haven't read the entire thread) have a look at your belts and pulleys. What size and profile are they? Are you sure the pulleys and belts have the same profile, and the belts aren't slipping in the pulleys? Some combinations of pulleys and belts look like they work together, eg Gates GT2 and the similarly named 2GT which have the same tooth pitch, but actually the tooth fit is poor and causes backlash. Other belt types, eg HTD, are designed to have more backlash, as the tooth needs clearance to engage with the pulley as it goes around! Matched GT2 pulleys and belts are probably the best for motion control in 3D printers at the moment.

Edit: Ah, sorry, just saw that you have changed the pulleys and belts!

Ian

Thanks for the reply. I did use all gates parts from e3d for belts and pulleys. The design of the printer does have the teeth running on smooth idlers, something that bothers me, but others have said it's not an issue, and there isn't anything off the shelf to change that either. Thanks for the links too! Glad to see a non delta machine getting the issue. I have looked into effector tilt and that makes sense. My homemade probe actually is a whole effector so while tilt is possible, but should be negated with the probe being in the center of the effector. I'm still of the mindset that when probing all 3 axis are feeding down and should cancel tilt and backlash.

Thanks again
Cory

To eliminate the issue of the arms being so horizontal at the bed edges as many people suggested was the problem, I got the longer 340.5mm CF rods and gave them a try. No real improvement

So a recap. New bearings, belts, pulleys, .9deg motors, carriages, glass bed, now longer rods. Giving up again unless someone has an epiphany.

Thanks
Cory

Replaced the idlers and bearings with new stock parts, even though I find it disturbing running the belt teeth against a smooth idler. Can't get 36 tooth idlers off the shelf. So it's stock, make idlers, or modify machine frame and double a couple points up. Belts and pulleys were replaced with gates parts. Very slight improvement.

Printed a delta calibration part and found the dimensions to be within reason. 60mm was dead on inline with the X tower, and about .2mm short inline with the y and z towers.

As good as it's getting. I've beat this horse too long. Everything but the frame and arms are new at this point. Thanks everyone for the input.

Cory

@danal Look back up a couple of posts at the bedmap before I overtightened the belts. That is why I replaced the 1.8deg steppes with the .9 deg. I had it through my head that at the towers the whole weight of the effector was pulling the down more due to torque loss at micro steps. Then between the towers there was 2 motors holding the weight. I saw zero improvement with them. If it's a bearing or something, I can't find it

As far as wider belts. I don't think there is anyway to put them in this printer without major mods.

Thanks
Cory

Thanks for the input.

I'm using the stock V2 effector and e3d hotend. Well actually an indicator and no hot end for testing.

I guess I was trying ask when I quoted dc42 is what error is accumulating? I agree it appears to be backlash, but it's not find-able by standard methods of measuring backlash. I understand that once you reach vertical that the end of travel. But until that point error of the horizontal arm should have very small influence in the Z axis, that is nearly solely dependent on the vertical arm. I did find dc42 mention that the delta solving method was 'probably more susceptible to rounding error' is this the issue?

I said a couple posts up that I thought it's effector tilt... I don't believe that to be the case.

I've been back and forth with belt tension. Last attempt was break it or fix it. So at this point, I think I've abused the belts and idlers plenty, bearings aren't free anymore. I'm going to replace them next.

Thanks again
Cory

I'm actually excited, I got worse results. The difference is that the pattern has changed a little. Not completely dependent on the direction on travel anymore. This time I ran the belts as tight as I had adjustment for. Now the axis feel pretty bad.

I have checked the bearings and belts several times at this point. Maybe a bearing is going lumpy under load, so hard to tell with the steppers in the system. The servo systems I'm used to don't ever feel rough, unless they are bad. Of course lots of times manually moving them isn't an option at all when they weight tons.

I keep ruling the bearings, pulleys, and belts out since the axis are consistent. But it's the only thing left to try IMO, it's either backlash from belts, or backlash from tight axis. Or both at the same time I think.

Seemecnc sells a flanged bearing for idlers on some other printers. Does anyone have an easy hack for the max v2? Maybe a toothed idler in in the places where the teeth are against the idler? Seems like that would be a smoother solution. I don't know if any line up on the V2. I'm thinking that I might machine out some replacement metal holders for the idlers, maybe screw them together through the bearing so the bearings will stay squared to the frame? Jack screws for the ones to tension the belts? I've tried over and over to get the belts to track perfectly, very little luck there.

Any thoughts on this? I"m going to at least replace the belts, pulleys, and bearings. Since I don't feel like I'm ordering parts that will fix the machine, I'm trying to upgrade as I do it. maker713's metal frame looks interesting, but at that cost I want the V3's bed mount and go with the AC heated bed. Then a 24V power supply would be easier and cheaper. The V3 frame is available but it looks like I'd be missing parts(like motor mounts) if I order the V3 frame kit from there.

Thanks
Cory

I realized that I skipped a post here as this is on going on 2 forums. Here is what I was getting.

I found a macro posted by dc42 to test backlash, I lost the results, but they were good at the X100 Y0 points. Then I rotated the program to run to the X tower and back, then the backlash shows up there.

I tightened the belts tighter again, I have washers under the heads and nuts so they hold without pulling into the wood(whatever it's spelled). Not much improvement there. They are too tight in my experience with timing belts, but I'm aware my experience isn't really valid here. At home position, the resonate frequency of the belt below the skate is around 130hz. Anyone know a good number?

The only play I can find in the system is that end play in the R4ZZ bearings in the cheapskates. The old ones had it and the new ones have it too. I looked for a couple hours in vain to be sure no one made a suitable bearing this small. It does make sense that it only shows up when the arms are so horizontal and the load is sideways on the skate. Another plus for longer arms, they'll shift that play into a direction of less influence. But there goes more build height. I was sure it wasn't effector tilt, because I assumed it would tilt about the center and that would take an obvious amount to create the error. But no, it tilts about the balls on the arm that is vertical.

So the auto-calibration route is obviously messed with by the crazy numbers at the towers. I added g1 x0 y0 z10 f6000 before every probing point in bed.g to pull the lash the same direction. Looking at the new bed map I should feed inwards before probing instead.

But this map is better for using the machine, I ran a large test print last night and got good results.

Coming from it as a machinist, then machine tool repair tech, I nearly have a new printer designed in my head. I'm certain that I'd be assembling it by now if I'd not spent all this time on this printer. And at this point I feel it is the next step.

Thanks
Cory