Here are 3 versions (5.0.0 and 5.0.1 and 5.1.0)
S3D500-Cube250micron_30m_15gr_PLA_T3500SE_08n.gcode
S3D510-Caps_2h40m_PLA_T3000SE_1n.gcode
S3D501-Cube300micron_40m_8gr_PLA_T3500SE_04n.gcode
Here are 3 versions (5.0.0 and 5.0.1 and 5.1.0)
S3D500-Cube250micron_30m_15gr_PLA_T3500SE_08n.gcode
S3D510-Caps_2h40m_PLA_T3000SE_1n.gcode
S3D501-Cube300micron_40m_8gr_PLA_T3500SE_04n.gcode
@dc42 Just to let you know we updated one of our machines to 3.5.0-b3 still with Simplify3D 5.0.0 and 5.1.0 no filament usage in the Jobs lists.
@dc42 said in DotStar not working from 3.4.1:
rameters. I think your LEDs were only lighting up in older versions of RRF because of the bug that we fixed in 3.4.
That worked out! A little more code to just dim the strip but we can dim it better than with the P value (that stops at 10 and R U and B goes down to 1)
@dc42 There is a white only dotStar which we use in our machines. We have large machines and can't use others as they are limited to number of leds. And we need at least white (color would be extra).
So there is APA102 (DotStar White) available which we use.
We only use P value to set the brightness level (works up to 3.4 beta 5)
When running 3.3 on MB6HC the DotStar leds (we use only white DotStar) are working perect with M150 X0 S10 P255
Updated to 3.4.1 they stopped working with any command, back to 3.3 makes it working again.
After some step by step updates we found out our system stops working from 3.4.beta6
Only changelog for DotStar is this in the beta6:
[Duet 3 MB6HC] With DotStar LED strip. If the brightness M150 P parameter (brightness) was not a multiple of 8 then the blue LED level was incorrect
@mfs12 We have just uploaded 3.1.1. and 1.24 and this still seems to work without any errors. to reproduce we just turn the machine on, please see our config below:
;T3D v2.5.1.1
M111 S0
M550 PTractus3D T3000 ;DO NOT CHANGE - NEEDED FOR PROCESSES
M540 P0x02:0x80:0xC2:0x02:0x00:0xFF
M575 P1 B57600 S1
M98 P"_UserSettings.g"
M552 S1
M555 P1
G21
G90
M83
M569 P0 S0 ;E0
M569 P1 S0 ;E1
M569 P4 S0 ;Y
M569 P2 S0 ;X
M569 P3 S0 ;Z
M584 X2 Y4 Z3 E0
M92 X80 Y80 Z80
M92 E290
M906 X1700 Y1700 Z1700 E1100 I40
M201 X1000 Y1000 Z1000 E6000
M204 P500 T1000
M203 X18000 Y18000 Z18000 E18000
M566 X300 Y300 Z300 E600
M665 R494.50 L1063 B500 H1660 X0 Y0 Z0
M666 X0 Y0 Z0 A0 B0
M574 X2 S1 P"xstop"
M574 Y2 S1 P"ystop"
M574 Z2 S1 P"zstop"
M308 S0 A"Bed" Y"thermistor" P"bedtemp" T100000 B4400 R4700
M308 S1 A"Hotend 1" P"e0temp" Y"thermistor" T100000 B4725 C7.06e-8
M950 H0 C"bedheat" T0
M308 S6 A"MCU" Y"mcu-temp"
M950 P0 C"exp.heater3"
M950 H1 C"e0_heat" T1
M950 F0 C"fan0"
M950 F1 C"fan1"
M950 F2 C"fan2" Q1000
M950 J1 C"e1stop"
M950 J2 C"exp.e2stop"
M201 X1000 Y1000 Z1000 E4000
M204 P1000 T1000
M566 X500 Y500 Z500 E1200
M106 P0 S0 H-1 C"Part cooling"
M106 P1 T50 H1 S255
M106 P2 T40:60 H2 L0.50 X1.0
M570 H0 P20 T20
M570 H1 P15 T20
M563 P0 D0 H1 F0 S"Hotend 1"
G10 P0 S0 R0
M140 H0
M307 H0 A119.9 C608.9 D1.4 S1.00 B1
M307 H1 A340.0 C140.0 D5.5 S1.00 V0.0 B0
M558 P5 C"e0stop" X0 Y0 Z0 F100 T10000
G31 X0 Y0 Z16.25 P500
M557 R400 S40
M208 S1 Z-0.5
M911 S20.5 R22.0 P"G91 M83 G1 Z3 E-3 F3000 M929 S0"
M579 X0.9926 Y0.9980
M912 P0 S2
M143 H0 P0 S110 A2
M143 H0 P1 S130 A0
M143 H1 P0 S300 A2
M143 H1 P1 S320 A0
M42 P0 S255
M42 P1 S255
M581 P1 T1 S1 R1
G28
@dc42 Nope, those messages, from the picture in my previous post, keep coming up every minute or so
Upgraded to the stable release, but still the same problem
We installed the firmware, but unfortunately it didn't solve our problems. Now we get a lot of error messages as shown in attached picture! We are currently running RRF 3.3 RC2 and WebControl 3.3.0 RC2 IMG_20210721_140124.jpg
Thank you very much, we are going to test it.
It happens from 3.2.x up and before we used (3.1.1 which was clean/no problems)
We even have it now on our small machines (desktop)
We are going to install the firmware now and will report within 2 hours with a result.
@Phaedrux resistance is in range and even much lower. We took a original cable (longest which was supplied before and meassured 3x as much restance. So this is not the issue as we think. Thanks for thinking with us.
@dc42 Thanks. The error parsing response is now gone. With the newest firmware we now have .....
Warning: failed to parse response move:currentMove: in state 12
Warning: failed to parse response inputs^:lineNumber: in state 12
Warning: failed to parse response inputs^:feedRates: in state 12
And some more.
LCD 7i is on FW 3.3.0-b
When we go back to 3.2.10 or 3.2.9 we still get Error parsing response
We tried from 115200 down to 38400 buadrate
Duet is on 3.3.0
It happens when we power on the machine. We build this machines as OEM vendor and never had any issues with our machines until last updates. For us the old firmware works fine but our customers want to upgrade and this results in fails.
Hopefully the error above gives a bit more details to help us out.
@dc42
-Replaced the hardware, we tried to go step by step and find out if it's faulty hardware or wiring. We've seen a lot of strange things happen. Sadly this is new for us and giving a bit of a headache.
What we see in our errorlog is sometimes:
Error: Bad command: N1557 M409 K"move" F"v"
or
Error: Bad command: N2559 M409 K"move" F"v"
or
Error: Bad command: M409 K"move" F"N2753 M409 F"d99f"*12N2755 M409 K"move" F"v"*113
So this directs me a bit in the software / bug side.
We downgraded both duet and panel to 3.22 and tried 3.3RC2 but always the same Parsing Response Error.
We use thick professional shielded cables in the machines which works in all our builded machines for 5 years now. So i can't believe it's the length of the wire suddenly.
Is there any solution for this? We have the same problem with 3.3RC2 and 3.2.11 (PanelDue). We do multiple machines a week but this is our first machine where we get this problem.
What we tried allready:
Look at your homedelta.g file
There are some lines that will put the head down a bit after homing. Still using H1 there will make it fail. Use the H2 to move the motors down a bit.
If you want a real stable temperature u need to have more isolation.
Make a hot airflow like a oven inside the inner chamber (heated one). Make that chamber isolated with some high temp material or use basic rockwool.
Next let cool air flow on the outer chamber to leave the outside of your printer cool so you can touch it.
We build a machine with 1m x 1m buildvolume and 200 degree chamber this way. Little bit more complex but for 90 degrees it's almost the same. If you need more help please contact me.
All our printers are using Duet boards. (Tractus3D)
Buildvolumes are from 20x30cm up to 100x210cm
I think i can say i have some experience with Duet3D boards and Dave's software.
For reference we produce printers from 3.5m tall and built more than enough of the smaller ones (60cm buildheight). All are using Dave's software. Never found a better supportive programmer than David!
Ofcourse there are bugs. Tell him and he will try to fix it. Don't expect it next day, but believe me he will try his best!
I see Jason is banned allready and that's good! If you don't know how much time is given by people for free! and are bashing them for it? Please leave...
Guys we all have alot of respect for you! Keep up the great work!
Found the problem, was playing around with 1.19xx before and not everything revert back to 1.18.1.
Now everything compiles again.
Hi,
I am trying to compile the RepRapFirmware 1.18.1 from the master branche
Keep getting a error in Eclipe Neon 2:
make: *** [src/Movement/Kinematics/Kinematics.o] Error 1
invalid initialization of reference of type 'const Platform&' from expression of type 'Platform*'
I don't know if this is the place to discuss it but maybe someone knows the problem.
Cheers,
Daniel
I had the same problems… disconnects and reboots of the machine after few moments.
Back to 1.18.1 now and everything works like a charm.
If you want me to debug/try more David, let me know.