This is an interesting one. In simulation mode it works ok. In print mode it will always trigger on the same spot in my test gcode. It also happens with other kinematics too, although the point in the gcode that triggers the fault is different for each kinematic type. GDB backtrace shows a fault occurring: #0 HardFault_Handler () #1 < signal handler called > #2 DDA:: Start #3 Move:: Staby sdavi - Firmware - experimental, borrowed, and future
Quotedot_bob I had a little free time last night so I gave the testingConfig branch a try on my MKS SGEN (basically an MKS SBase without on board drivers). A few things I observed... It appears the endstop min <-> max order is reversed in the boards.txt. According to documentation from MKS the pinout is the same as the SBASE but I ended up needing to flip the max and min endstop pin defiby sdavi - Firmware - experimental, borrowed, and future
Updated to DC42's RRF 2.03Beta2. I've also made some changes to HTTPResponder that should hopefully stop DWC getting stuck in an endless reconnecting loop when the buffers run out. In the beta2 update, DC42 also changed M111 so now debugging won't be enabled by "M111 S6" - this should help those using repetier-host. Updated binary in the configTesting branch. @DC42 The issue was the buffby sdavi - Firmware - experimental, borrowed, and future
QuoteMKSA So far so good. Note I didn't check if there was still this com issue with Repetier in debug mode as I don't use it anymore and removed it. I don't use the network either. I think for the next release I will just end up disabling "M111 Sx" and have it print a note that it should be used along with with the P parameter to enable only the modules they want to debug. That would at leastby sdavi - Firmware - experimental, borrowed, and future
Very experimental LPC build of RRF in testingConfig branch (also includes 2.03beta1 merged in from DC42's branch). Some have requested a config approach to set pin mappings to avoid recompilation etc and I've started implementing that, and included an initial preview of the new board config loader - this is still early days for the config system so things may still change and there may be bugs inby sdavi - Firmware - experimental, borrowed, and future
Quotedot_bob Well after playing with the firmware the last couple of nights I have it running on a couple of printers and added support for the BIQU SKR board. I have submitted a couple of pull request with these changes. I have been playing with the MKS SBASE trying to get networking and the discount reprap full graphics display running reliably. The hardware was designed pretty poorly as theby sdavi - Firmware - experimental, borrowed, and future
Quotedot_bob I just purchased a couple of Duet 2 WiFi's from Matter Hackers and while I was attempting at getting one running on a coreXY I stumbled upon this port. I have a couple of machines that run on Marlin 2.0 with a MKS sbase, RE-ARM, and AZSM mini. I plan to try this port on most of them. I am starting on a Tevo Little Monster delta which is mostly stock but comes with a MKS sbase staby sdavi - Firmware - experimental, borrowed, and future
I don't have a SBase so I don't know how much current its drivers can output, but if it helps, I built a 700x1000mm OX CNC with Nema23 motors: 3x 23HS22-2804S (2.8A 178oz.in) 2 for the Y and 1 for the X, and a 23HS16-0884S (0.88A 85oz.in) on the Z axis. I run the X and Y motors at 1.7A and the Z motor at 0.77A on a Smoothieboard running on 24V. It works well for me, although I don't push it veryby sdavi - Controllers
QuoteJoVo could it be that web control something cached? Now lot of hour later webgui is stable (I configured dual-z today - works also ) Last issue for me is Temperature (Chart) this is not a straight line - it has a lot of spikes up to 10 C ° most of them up to 5 °. For some test prints, the system was stopped due to incorrect temperature. PID was done. Check the values of M305 and make surby sdavi - Firmware - experimental, borrowed, and future
QuoteJoVo For MKSSBASE-NETWORK it works also ... two little issue: Webgui is not so stable as before - lost connecting twice and "LogicalPin" the number changed 62 to 60 so my fan would not work Ah yes thanks for pointing that out, I forgot to mention that the Logical Pin numbers might have changed for some boards as the previously unused endstop pins are no longer listed as spare pins. Therby sdavi - Firmware - experimental, borrowed, and future
New binaries with experimental support for boards with Min/Max endstops. **Upgrading to this version you need to check endstop configuration and connections** This should now allow M574 to select the position of the endstop, and it now also updates the RRF endstops array to allow it to select the hardware pin corresponding to Min or Max. This also now requires the probe to be selected with P4by sdavi - Firmware - experimental, borrowed, and future
QuoteJoVo That sounds good. I will test today. You say up to 10 ajax retries. I'll try. Yesterday I provided the test printer with limit switch(s) and wanted to try to make it work. The first print attempts I made were not great - layer shift - but that's probably my mistake. Thx for your great work Did you add the pulse timings to M569 for the DRV8825s in config.g?by sdavi - Firmware - experimental, borrowed, and future
Small update for Networking users. Updated network driver to accept broadcast ethernet frames to allow the board to reply to ARP requests. Although FreeRTOS+TCP defaults to frequently sending gratuitous ARP, some OSes do not accept them by default resulting in their ARP tables not being updated. Tweaked the network related buffers, freed some memory by not creating the ftpresponders which wereby sdavi - Firmware - experimental, borrowed, and future
Quotedc42 In RRF 2.03 I'll be adding a new M-code to assign endstops. Endstop inputs are already numbered from 0 to some maximum in other commands such as M591. The mapping is currently fixed at X=0, Y=1 etc. and that will become the default mapping in firmware 2.03. The new M-code will also provide for using multiple endstops on a single axis, which will avoid the need to create additional tempoby sdavi - Firmware - experimental, borrowed, and future
QuoteJoVo first I'm new to reprap .... I try M558 P7 but I've also M574 Z1 activated (that could be my prob) Yeah, currently the Z-Min (on the board) is configured to be what RepRapFirmware considers the "Probe" pin so probably P5 should work. I think in your current config it is expecting the probe to be on the "RRF Z endstop" (which is currently Z-max in the current port). The current duetsby sdavi - Firmware - experimental, borrowed, and future
With the endstops, it might be possible (have to look at the source code for endstops etc) to select the hw min/max using M574 as it configures the X,Y, Z endstop as no endstop, low end, high end. It is the probe which is the only issue. I assume most people use the unused Z endstop for the probe? So can we assume it will normally be on a Z-min or Z-max connector? So we can either modify GCodby sdavi - Firmware - experimental, borrowed, and future
Updated MKSSBase config based on this config.txt and binaries uploaded. The config is now (please check these are now correct): Bed: Therm - 0.23 and HeaterPin - 2.5 Hotend1: Therm - 0.24 and HeaterPin - 2.7 Hotend2: Therm - 0.25 and HeaterPin - 2.6by sdavi - Firmware - experimental, borrowed, and future
QuoteJoVo so now with network + usb (works today ) === RTOS === Static ram: 2792 Dynamic ram: 29340 of which 0 recycled Exception stack ram used: 296 Never used ram: 308 AHB_RAM Static ram used : 17504 === Ram Totals === Main SRAM : 32428/32768 (340 free, 308 never used) RTOS Dynamic Heap : 38352/44536 (6184 free, 5016 never used) === LPC PWM === Sounds like there is some intermittent pby sdavi - Firmware - experimental, borrowed, and future
QuoteJoVo That are the values after a "cold start". === RTOS === Static ram: 1740 Dynamic ram: 30348 of which 0 recycled Exception stack ram used: 256 Never used ram: 392 AHB_RAM Static ram used : 10784 === Ram Totals === Main SRAM : 32344/32768 (424 free, 392 never used) RTOS Dynamic Heap : 33712/52304 (18592 free, 18592 never used) could be interesting after few hours playing around..by sdavi - Firmware - experimental, borrowed, and future
Apparently a few people also had issues with the supply to the phy chip on the sbase too. I run 1.22.5 on Smoothieboard and find it stable with the LPC port - I've had it running for several hours without any problems. I've been testing DWC v2 with LPC port and so far the main issue i've experienced is it "disconnects" when uploading large files since it also seems to be requesting status updaby sdavi - Firmware - experimental, borrowed, and future
Merged in updates from RepRapFirmware release v2.02 and new binaries uploaded. Read DC42's WHATS_NEW to see changes in RepRapFirmware 2.02. LPC Changes: * Implemented firmware update command for Networking users. After installing this update, users can hopefully upload future firmware files (do not rename when downloading) using DWC by uploading via the upload button in the settings page whichby sdavi - Firmware - experimental, borrowed, and future
QuoteMKSA Any reason the MAX end stop pins have been chosen for the limit switches instead of the MIN which seems to be the most common and logical (coord 0) set up. When moving from Smoothieware, I had to reconnect them, not a major issue but an hindrance when you go from one firmware to an other, but I am asking because I can see the MAX being usually free can and are used for other kind of inby sdavi - Firmware - experimental, borrowed, and future
QuoteMKSA - MKS blatantly copied/adapted/stole most Smoothie designs but selected different drivers. Therefore I wonder if they have really chosen Rsense in order to get the same formula.(formula is a bit pompous, just basic arithmetic ) to match the one used by the Smoothieboard. I managed to measure the Vref (all is so tiny and under power, risky ) and when I refer to MKS schematic and 8825 dby sdavi - Firmware - experimental, borrowed, and future
QuoteMKSA Hi, Some question for you or DC42 The MKS uses 8825 drivers (I start to dislike them BTW ! ), not the same drivers as the Duet board, so how is the proper Vref for the 8825 determined from the M906 command to set the current specified ? Did you change the formula or may be, luckily , it is the same as for the Duet ? How is the command M305 handled (microstepping interpolation? Note oby sdavi - Firmware - experimental, borrowed, and future
QuoteMKSA Hi, Latest MKS bin works OK so far. Just for Repetier that is OK with all debug option off yet still hangs as before when any debug option is on. Just an annoyance as far as I am concerned. I print off line from the TFT32 standard SD (easier to handle than the microSD on the MKS SBASE). Is the network version stable as of now ? I may give it a try in the near future although no Wifiby sdavi - Firmware - experimental, borrowed, and future
Binaries updated to RRFv2.02RC6+. I've just merged in the latest update by DC42 to fix that assertion fault.by sdavi - Firmware - experimental, borrowed, and future
Binaries updated to RRFv2.02RC6. LPC changes (includes some recent fixes mentioned earlier): LED definitions now included in board variant. Reset reason now included in M122 i.e. Power on, software reset, brown out detection etc. HardwareSerial rewritten to use UART functions from LPCOpen, and also now includes a transmit ring buffer in addition to the receive ring buffer. AUX serial now defauby sdavi - Firmware - experimental, borrowed, and future
I've managed to track down that Assertion Failed error that some users are getting when debugging is inadvertently enabled. @dc42 I can also replicate this on my Duet Wifi as well. Connect over usb, enable debugging, set kinematics to CoreXY, home an axis such as G28 X, trigger the endstop. From GDB backtrace, the issue arises from debugPrintf eventually calling RawMessage from within an ISRby sdavi - Firmware - experimental, borrowed, and future
Quotedc42 @sdavi, if your new binaries are based on the RRF 2.02RC6 release, you should have around 1.7K extra RAM available. I was able to reduce the stack size of the Main task in RC6, because it no longer needs such a large buffer for GCode replies. I merged in 2.02RC6 last night and testing it now. Great job getting the memory usage down even further. With all the recent memory savings we noby sdavi - Firmware - experimental, borrowed, and future
Binaries updated again. I think the AUX serial should be working properly now. This is experimental so be sure not to leave unattended especially if trying to print over that interface (only tested with RRF running in simulation mode). It is at least working with a PC host application so hopefully the TFT will work now too.by sdavi - Firmware - experimental, borrowed, and future