@dc42 said in N539/N538 not working in 3.4:

Sorry about the late response. I took the machine apart a month ago for some modifications and it took a month+ to receive the parts. I'm in the process of putting it together again and some reprogramming will be needed too.

@3discnc said in N539/N538 not working in 3.4:

I was using N539 in RFF3.3 on the 12864 LCD; in 3.4 it shows 0.

Thanks for reporting this. I have now fixed it. The fix will be in 3.4.0 stable.

I am designing a replacement G29 grid scanner and run into the limited string space of RFF. I cannot find any means to truncate a float and so cannot pack enough floats (17+?) into this limited 120 byte string space. Any advice on this?

Perhaps you could use multiple strings with fewer floats in each?

Already tried that but how do I put the two strings in the height map as a single sting (i.e. no CR/LF)?

Since there are no arrays I had to resort to 20 variables. Apparently these are not directly addressed or looked-up but searched for at each access, this makes them very slow. The further down, the slower. Perhaps something to look into. I've shortened the var's to two characters, that helped a bit

We will probably support array-valued variables in RRF 3.5.

Those will be welcomed with open arms!

I also have no clue how to use '#' to get a stringlen value. How is this supposed to work?

Trivial example:

echo #("hello"^"world") 10

That takes care of strlen() but, it would greatly help if I could truncate strings since I don't need fractional nanometre resolution (yet). ;o)

My Maestro manages to erase the CD card from time to time. I've seen this happen on several crashes into the X end-stop and a (probably) non ending loop.

Does this happen while your macros are writing to the SD card?

Don't really know and also it does not happen every 5 minutes. I home (or some process) the machine and it crashes as soon as X-stop is hit. The LCD is emptied and the Maesto does not respond of even reboot. On my PC the card is not recognized (Windows asks Reformat Y/N?). I reformat and copy a backup onto the card and all is well. How well depends on the amount of work lost. I was intensively modifying the system macros over the network, with the accompanying reboots and whatnot.

@Phaedrux Will Do Thanks.

@Phaedrux
Thanks a lot for the help.
I actually went through that tutorial before.. but, now it just works.
Didn't have to change a line and was few hours on that already,
I have no clue what happened... but happy o/

Mosfet usually fail always on (or catastrophically to the point where there is nothing left of the part)

So if the fan works on the always on output but not on Fan0 before and after the replacement its not untinkable the fault is elsewhere, unfortunately the next part in the chain is the main processor (FAN0 goes straight to pin 90 on the ATSAM4S8C)

To further diagnose verify the part has connectivity from the Gate to R42, from the Drain to Fan0- on the header and from Source to ground. Then (with power on) check if you have a gate signal on either side of R42 with respect to ground when the fan is turned on.

7e51baf8-718b-4112-bf12-47cc46fc8f10-image.png

@Phaedrux Thanks 🙂

@dc42 said in Probe Accuracy Test Macro [Issues]:

@CCS86 said in Probe Accuracy Test Macro [Issues]:

@dc42: Does it sound like a bug for the probe offset to be applied over and over on repeated G30 P3 X0 Y180 Z-99999 F2000 calls?

That doesn't sound right. Please post the complete macro file you are running, and your config.g file, and tell us which firmware version you are running.

I was originally on 3.0, and now on 3.01-RC4

Unfortunately, I did not save the macro before modifying it. That is my fault.

I did find one error in my code, in asking it to probe at X0, when my probe has a +12mm offset. I feel like the firmware should catch this more gracefully though. It appears that it ignores the endstop switch and the X0 minimum designation, and tries to aggressively get the probe to X0 anyway, which hard crashes into the machine limit and jumps the belts.

Also, it appears that I can't probe more than 32 points before I am "out of range"

f5cb5f29-c4cd-481d-8a66-404810d82659-image.png

Have you disconnectede everything from the Duet except USB?

Are any components getting hot? In particular, check the SD card, W5500 chip, and main processor.

@tcj said in Maestro and other types of 12864 LCD?:

Thank you for the information.

Do you know less "bulky" LCDs than the typical reprapdiscount type?

I'm sorry, I am not familiar with all the different 12864 displays on the market. We chose to support the RepRapDiscount because it has been widely cloned and is in widespread use.

When we revise the design of the Maestro, we'll look at providing another level-shifted output so we can support these other types of 12864 display.

@dc42

Hello!

Checked what you said and it solved my problem.

For some reason the cables on the endstops were ALL wired incorrectly (and all were different in the way they were connected) so I checked everything with a multi meter and everything is no correct.

Also i needed to set them to normally open instead of normally closed.

Everything is now homing perfectly as it should. On to the next bump!

Thank you for your help!

That got it working! Thanks for the suggestion.

BTW: flashing the firmware with BOSSA on a Mac worked without a hitch.

this happen to me i fix by going to endstop config and switch from false to true and that fix the homing problem

@dc42 said in Extrusion setup question:

Which version of Duet Web Control is it running? Look in the Settings General page to find out. The latest version is 1.22.4.

Thinking about this more I wonder? If I change the config file and reload the firmware without power cycling the board or force reloading the Web interface, what are the chances I would get some of the behavior I was seeing? What determines the button actions, and can they get out of sync with config.g?

BTW, I believe the default micro stepping when I installed the board was 16 for XYZ and 8 for E. With this as a starting point it's likely things went off the rails for reasons I didn't grasp at the time. There was definitely a period where the web interface was not in sync with what config.g was set to. And it persisted through reloading and power cycling because it happened of the course of several days.

@simplesimson said in IR probe and Duet Maestro:

Hey,

i´m still having the same problem. Do I need to use M558 P2 for the "digital probe"? if I do so, the Probe Z status in DWC shows 0 (5) when not triggered and 0(1000) when triggered. By Triggerd i mean a red LED.

Sorry for the late response. M558 P1 is correct for the IR sensor that we sell. P2 is only for the sensor that RepRapPro included in the Ormerod 2 printer and I think also the Huxley Duo and one of their Mendel printers.

@genghisnico13 Fantastic. Thank you. I was worried I had a bad board! On to figuring out why my cold temps are so low..