Posts made by travasky

Any update from anyone on this front? Ive just been running the machine without the probing which is less than ideal. @dc42, Is there anything you can add to help us out here?

@br7408 said in Scanning Z Probe giving erratic Z values:

I am getting ready to install my scanner probe. I found the instructions overall very vague and unclear as well. I'm normally pretty good at doing my due diligent research on most of this stuff and coming up with answers, but this one has me scratching my head.

Could we possibly just get a full step by step instruction process for the scanning probe, in one place, written a little more clearly?

I felt exactly the same way. I know the SZP is relatively new and there are a lot of things going on all the time with code and hardware and how they mix. Documenting all of that in a way that is widely accessible is hard. I feel like these instructions read more like notes I would write to myself as reminders after I was already familiar with the process. Please don't take that as criticism made in bad faith, @dc42. Just my perspective as an end user. I'd say the vast majority of the documentation has been just fine, but this one area isn't clear for me.

Ive done three industrial control swaps on machining centers with Centroid hardware, built other custom printers based on Duet 2, etc so I know I should have the skills to figure this out but its just not coming together for me this time.

@dc42 I have done this several times now. Unless I'm misinterpreting the guide, Im not sure what I'm missing. I'll walk through my process and understanding based on the guide:

"Position the sensor above the bed at the minimum height that you expect to use it.
For example, if the trigger height is set to 3mm, and the bed error is expected to be not more than 1mm, the minimum height would be 2mm."

In my case my sensor is above the tip of the nozzle by 3mm. I bring the nozzle to within 1mm of the bed. Set the trigger value in the G31 line in config.g to 4mm.

SIDE NOTE: Ive tried this with a number of different heights by the way. My bed is virtually flat (.05mm over the whole surface as measured with a dial indicator) so Ive tried this with different values all the way down to where the nozzle is .5mm from the bed surface.

"Run M558.2 K1 S-1 to calibrate the drive level. If it is successful then it should report the resulting drive level."

Done. Value is S16 R146320

"Add an M558.2 command in config.g to set that drive level, e.g. if the reported drive level after calibration was 15 and it is probe #1, then use M558.2 K1 S15. Add this later in config.g than the M558 K1 command that configures the probe."

Added results from previous step the config. In my case there are no other probes so I've omitted the K value. None of the other commands referencing the probe in config or the homing files use the K value either so Ive made sure there's no mismatch there.

Also check that the Z probe reading is sensible when the sensor is a long way above the bed. The aim is to get sensible readings (i.e. not 999999) from the minimum height to "infinite" height.

Im a bit unclear on what this step means exactly. But I can tell you that at this point the values are jumping around. I haven't moved the head from the initial location that I used to calibrate and sometimes Im getting 999999. Moving the sensor futher away from the bed sometimes changes the value, sometimes its just pinned at 999999, sometimes it jumps around. What should the sensor values look like in relation to the distance to the bed? IE, lower values when close and higher when further? Whats the sensing window?

The reading vs. height then needs to be calibrated, using M558.1. If you have another way of determining Z=0 (e.g. another Z probe, or touch the nozzle to the build plate and set G92 Z0) then it's best to do this immediately before scanning rather than try to save the calibration.

This step felt vague to me. But what I did was bring the nozzle down until it touched the bed. Then I ran M558.1 which gave me a probe not calibrated error. I assumed I was missing a term here, So I pulled up the RepRap g/m code reference and saw that I probably need an S value. I set it to 1mm and tried again. Now it gives me a successful calibration. But still no changes on the function. When I home I get a g30 error that the probe is already tripped. If I move the nozzle closer or further from the bed the values still jump around erratically.

What am I missing here?

Update:

Upgraded to 3.5.0 across all hardware and still get fluctuating readings. I also attached a ground wire directly to the head and saw no improvement.

@Phaedrux I'm running 3.5.4 because I was under the impression that using the SZP as the sole Z probe wasnt possible on anything 3.5.3 and below. Am I mistaken?

EDIT: I see my mistake on the RC / release nomenclature. Yes, Ill update tonight.

I can take photos of the wiring this evening. I'm also considering running a temporary ground wire to see if its just a noise issue. There is full continuity between the head and machine chassis (Stratasys STS1200 so its completely metal construction) but maybe Im not seeing something, so its worth a test I think.

I should also add that this SZP is used as the Z limit as well. There isn't a lot of documentation yet on how to set this up properly so I'm cobbling together an understanding from posts here on the forum and results from the RR config tool. Also, I am running 3.5 RC4 and both the 6HC and SZP have been updated.

I have a SZP Im setting up on my machine. Its connected to the 6HC via a twisted pair of wires from the tool head approximately 1 meter in length. I've been struggling for hours trying to get it set up. Whenever I attempt to home the Z Axis i get a G30 error that says the probe is already triggered at the start of the homing move. The value in the status pane of DWC shows the probe value erratically bouncing from 5000 or so to 999999 every second or so. Ive checked the 5V signal at the SZP board and its a rock solid 5.01V. Ive also tried both coils with identical results. Im at a loss here. My Config.g is attached if thats helpful at all.

config.g

@br7408 I used slightly undersized countersunk screws. Its not ideal but it does the job. IMO this was an oversight on the board design. Some PEM inserts could potentially solve it going forward. You could even try using some of their press in inserts if you wanted to give it a try yourself.

@OwenD
That worked. Funnily enough, I swear I tried that exact same format once before. In any case, thank you for the time to make the suggestion. All in all I think that solves the functionality issue, but still the formatting error is something @dc42 can look into in case its affecting others as well.

@dc42 Here's the file.
daemon.g

@OwenD
The goal is to have the chamber fans turn on any time the heating elements are running. Not every filament will require chamber heating so I avoided the thermostatic control because I don't want the fans to kick on as the chamber naturally heats from the bed.

I tried the heat.heaters[2].state but I couldnt figure out what to put afterwards. Based on what I read in the object model docs I put heat.heaters[2].state==active but it didnt like "active". Any advice? The coding side of things isn't my strong suit.

I had the following code in my daemon.g which worked. under 3.4.5
I upgraded to 3.5 RC4 today and now get the following:
Error: in file daemon.g line 4: Illegal parameter letter '.

if heat.heaters[2].active==1
    M106 P1 S1
else heat.heaters[2].active==0
    M106 P1 S0

I dont see any obvious issues and also tried uploading a new daemon.g made in notepad++ in case some aspect of editing in the browser was introducing formatting errors. No luck though.

I did some more playing around with the config tool and the issue seems to be directly related to the "Z Probes" section. If I select the SZP in that section the tool will throw an error every time.

Im trying to use the config tool to generate my config files. When I click to download the config bundle I get an error message pertaining to the config.g file. Since I can't copy the error text Ive attached photos:

And Ive also attached the config json I used that generated the error.
configtool.json

Any help is apprecaited!

@jens55

Just opened up the sides to check the PN. Here they are: https://www.selcoproducts.com/product/12-disc-thermostat-manual-reset-om-250

@jens55

The heated side chambers have thermal fuses. I’m not sure what the ratings are but Stratasys deemed them appropriate.

I read a bit more about the daemon.g file and the object model. Again this is way over my pay grade but could I get away with just monitoring whether or not the chamber heaters are active and the turn the fan on if so? Like this:

if heat.heaters[2].state == active
M106 P3 S1

Where the chamber heater is heater 2 and the chamber fans are fan 3

@oliof The hardware side of things is my strong point but the software side, less so. Is there a good guide that would get me started down this road?

@soare0 The fans are DC, the chamber heaters are AC. But the bigger issue is that the chamber heaters will need to be controlled with a PID loop so there are moments when the fans would be off if the heaters are off. The air still should be circulating during the whole print.

@dc42 As above, different voltages and I don't want the fans to turn off when the heaters have reached temp or between "bang bangs".

@sebkritikel I actually did read through that thread a few weeks ago. There's a surplus of I/O on the Duet board - at least for my design. I ended up just doing a full on gutting of the machine and Im doing all new stuff. I've only retained the chamber heaters and fans, LED lights at the front of the chamber, and part cooling fan. The idea of doing all the work to interface to old and hard to find hardware just didnt feel worth it to me. Because Im using the SBC Ive added a 10" touch screen with some buttons below that control the material cartridge drive motor and solenoids. Ive also designed a circuit that controls the cartridge latching system. Ill probably design new cartridges that allow fast and easy material swaps. My current build only has a single extruder but once the machine is up and running Ill start on a dual extruder model with tilting hotends similar to the original design (mechanically actuated instead of servo driven like you see in other hobby machines).

@mrehorstdmd how are you getting around the fans turning off / pulsing when the chamber hits the target temp? In the original machine fans were on 100% of the time the machine was on. In my case I'd like the ability to control them if I decide to print a material other than ABS for example. I added a heated bed to give me flexibility on materials instead of the plastic build plate that was passively heated on the original. Seems like a shame to not be able to use or not use the fans at will.

I'm in the process of retrofitting and rebuilding a Stratasys SST1200. Ive chosen the Duet3 6HC since Im familiar with the older Duet 2 boards from previous builds. This machine uses two resistive heating elements which Ill control with an SSR via a standard output channel (OUT9 in this case). However, any time the heaters are on, the chamber fans must be running also. This blows air over the heaters which sit in side compartments and then into the main chamber via two air knifes. I'm familiar with thermostatically controlled fans but in this situation the temperature isn't the deciding factor as to whether or not the fans should be running. Instead, if the heaters are being used, the fans must be on at full power. What is the best way to implement this? FYI, these 4 fans draw more current than any of the other devices so I've planned to assign them to OUT 0.

@CarlBosson The water cooling system should always be running - the same way a hot end fan would be and youll want to do your hot end PID tuning with the pump running. Even though heat creep across the heat break should be very small its still pulling energy out of the hot end.