Topics created by Vlad

@vlad said in Duet2wifi with 3-4 wire fan, wiring:

@dc42 Thanks David, and nope, I actually connected everything exactly according to that instruction. red and black went to always on fan, and PWM wire went to "-" lead of Fan0.... very weird, I will speak to fan manufacturer, its definitely possible that they messed some wiring up. really nice fan that is, really want to make it work with all my duet setups.

Yes that's odd, assuming you didn't connect the PWM wire to the + output of Fan0 by mistake.

If you connect a multimeter between the FAN- pin of Fan0 and ground, it should register no voltage, whether Fan 0 is turned on or off. Caution! Be very careful when probing the fan output pins, because it is very easy to short both pins together, which will blow the fan mosfet if the fan is commanded on.

Cool, I believe the amp is already included in that product that I have purchased. So just a comparator circuit then. Do you think a MOS module or an SSR could do a trick there (could be stupid question tho 😛 )? Ideally I will want to only do that procedure once a year or less, will see how sturdy my frame is once I get the machine up and running. I decided to first try to use hall effect sensors for homing and manual leveling procedure and try to store those leveling coordinates int he firmware. hall effect are very precize sensors and theoretically I shouldn't "need" to reprobe it at all. But that all is only a theory that requires testing still

@Vlad is it one of your boards that you're having this problem with, or a genuine board? Again, please post your testing method and gcode so we can test what you're seeing.

Ian

@dc42 said in Need a little help/advice on PanelDUE on coding it:

Actually it's not impossible. PB6/SWDIO goes to X4 the expansion connector, so it's free. PB7/SWCLK goes to RST on the LCD connector, so you could cut that trace and connect to it. The LCD may not need the reset signal, but if it does you could add a push button. You would need to modify the startup code not to program the bus matrix to use those pins as GPIO.

But I've never had to resort to a debugger when developing PanelDue code.

I was considering that as well, but i'm a bit hesitant about modifying the PCB by cutting traces.

But this helped! Thanks

@dc42 nope, logging is disabled already. I tried it but it didn't give any useful info. If I can edit that file myself, I will try that as well. I would increase the delay significantly, to 500 or so and do 5 retries. I will give it a try if I can. M122 last time reported absolutely nothing, like it wasn't even retried once.

Ok just checked, I can't. I guess it needs to be compiled into .bin then, I have no way to do that.

If you are running recent firmware (e.g. 2.02) then the firmware already does a number of retries before it gives up.

In the early days there were occasional QC issues with the soldering of the pins at the back of the SD card connector, but that item is checked explicitly now. But if you are getting these problems frequently and you have already replaced the SD card, then it might be worth inspecting that soldering.

The M122 report includes the maximum retry count that was needed to get a successful read or write.

@zapta said in incorrect print time estimates (S3D), layer count etc:

@dc42, I wonder, board developers like you and slicer developers like Cura, S3D and Slic3r are on both ends of the same gcode protocol. Are there forums or communication channels between the two groups? For example, to discuss standard representation of estimation metadata that slicers can pass to the boards.

If there are any such channels, I am not aware of them. Every slicer seems to use different metadata keywords, and they often change.

Thanks guys. My hotend doesn't have any heat creep like that, so it was not logical to me, but now it is clear! I'll just leave it as it is now.

There's also a difference between RC and beta releases. Beta releases often include large changes and experimental features, so they are more likely to include bugs. RCs are intended to be close to what we ship as a stable release.

@vlad, yes it's essentially an architecture limitation i.e. lack of a large RAM buffer, and to a lesser extent the use of SPI to transfer the data from the WiFi module. I have just tested the SD card write speed on the Duet WiFi on my bench using M122 P104, and I get speeds of about 1.6Mbytes/sec all the way up to 200Mbyte files. This is with a Kingston Memory 8Gb Class 4 card. I don't think we will do much better that that using the current 8kb write buffer. The problem is, once the card sees the end of the 8kb block write, it may start to do internal wear levelling operations, and those take time.

I am also minded to add another M105 subfunction that tests the speed of uploading a file but discards the data instead of writing it to file. This would help users who are getting slower than expected uploads to determine whether the SD card or the WiFi network is the bottleneck.

We recognise that users want faster upload speeds, and we have addressed that in Duet 3. However, by better overlapping transfers from the WiFi or Ethernet module with transfers to the SD card, I am hopeful that in as future Duet 2 firmware release we can achieve more than 1Mbyte/sec consistently, assuming a good WiFi connection.

@dc42 Regarding the board question. Filastruder, couple years ago. They are as horrible in attitude and customer service as you are. Also were very disrespectful and gave me a lot of trouble when I asked to return a heavily flawed 7inch screen. Provided video evidence, and they tried to pull some lies on me. Even said that could not see the problem when they received the screen. Horrible company and liars. I am glad matterhackers are my neighbors so I don't have to deal with inferior unprofessional distributors anymore.

As for the board, if I received such quality product from one of my Chinese suppliers, they would have to redo all order for free and this would go into garbage. Speaking of quality standards. And I didn't say a word. But when you are rude on top of selling overpriced inferior quality board, that's already too much for me. Anyways, good luck in your business. I am out. I deleted a link, since it bothered you so much. You can be in peace now, and not waste energy on something that has zero importance.

Can't you have the board repaired? It would probably be cheaper then replacing it?

@elmoret Thanks. The board is a paperweight now and is out of warranty already I assume. Weirdly failed after I connected a display via UART... oh well. What else can go wrong with that thing. AS for your civic comparison, I have a tesla, but I do not spend money unwisely like that, otherwise I would have had a civic probably with ford engine lol. I also prefer buying on amazon for convenience reason. Assembled car is a finished market product, and here we are talking about DIY item, so it is weird that you even compare roaches to apples here. I am not sure how many days you are in DIY hobby for, but buying a different "brand" of the board with same functions, is actually what is going on all over the place. We are not on gucci page here, it's a motherboard. DO you also oly buy duet sensors and duet heaters? Then why not buy a DUET 3D printer and not do anything at all? lol. I do not see any problem using adafruit board, and the only single issue of me not being able to use it is that the pinout for a DIY electronic component is not shown anywhere, including the pinout of their own add on board. And I made it work by the way, figured out ports on my own, by duetwifi schematics.