LPC port of RepRapFirmware

Quote
MKSA
Hi,
Wanted to play with RRF on a MKS SBASE 1.3.
No network and I use Pronterface via USB to talk to the board/printer.

Last week, I installed the "firmware-SMOOTHIEBOARD", managed to bring the machine to live (motor, endstop, heater ...).

Now, I just replaced it by your latest: firmware-MKSBASE and nada, yes, the firmware changed to .cur, I can connect via Pronterface but when trying to home, error msg can't find the G code ( home ....) although they are there as before ?

M21 command returns SD card not usable ? (2G Sandisk)
Changed it for an other one (8G ) and it is seen, so home, motor etc... OK

So the firmware can load from the SD but can't read it ??????

PS: Would be nice to have a separate sub forum for RRF, like for Marlin

This has been a known issue for a while, and remains a mystery. I have a 4G card which came with the smoothieboard which also has the same issue, but no problems with any of the the other 8 and 16G cards I have.

Flashing the firmware is done by the original smoothie bootloader which is why it will flash the new firmware. It's frustrating as I know the card should work, and I've spent a while before and traced it back to the card init CMD8 call that returns incorrect response. I might go back and see if I can track that one down.

Quote
dc42
Most discussion about RepRapFirmware takes place on the Duet3D forum, [forum.duet3d.com]. There is a subsection for RRF on non-Duet controllers there. I'll leave it up to @sdavi to decide whether he wants to use that, or continue here, or request a forum for RRF here - perhaps with your support.

I'm happy to use both forums.

Hopefully I've tracked down that odd SDCard issue.

Uploaded new binaries - this update sends an extra 8 SPI clock cycles before sending the commands to the card and all my cards are now working.

Quote
sdavi
Hopefully I've tracked down that odd SDCard issue.

Uploaded new binaries - this update sends an extra 8 SPI clock cycles before sending the commands to the card and all my cards are now working.

OK, it works.

As I use USB, not the network (no WIFI on the MKS), will the SD card be able to be accessed from the PC/USB (saw in the first post it isn't currently possible))? I want to copy from PC to the SD via USB then initiate the print from it.
I don't like to print from my PC via USB.

I also have the MKS TFT32, is it supported ? Would be nice, the SD card slot in it is for the normal size, easier to handle than the tiny microSD on the MKS board.

Thanks

PS: To compare to Smoothieware, I tried to reload it and it doesn't load anymore ??? I can sill reload RRF though (I did the upgrade OK). Did you modify the bootloader ?

Edited 3 time(s). Last edit at 12/11/2018 02:55PM by MKSA.

---

"A comical prototype doesn't mean a dumb idea is possible" (Thunderf00t)

Quote
MKSA
OK, it works.

As I use USB, not the network (no WIFI on the MKS), will the SD card be able to be accessed from the PC/USB (saw in the first post it isn't currently possible))? I want to copy from PC to the SD via USB then initiate the print from it.
I don't like to print from my PC via USB.

I also have the MKS TFT32, is it supported ? Would be nice, the SD card slot in it is for the normal size, easier to handle than the tiny microSD on the MKS board.

Thanks

PS: To compare to Smoothieware, I tried to reload it and it doesn't load anymore ??? I can sill reload RRF though (I did the upgrade OK). Did you modify the bootloader ?

No, RRF does not show up as a storage device on the PC.

I've not see the MKS TFT32 before. From what I can see, it appears to be a standalone device that acts as a host ?

The firmware does not modify the bootloader. To load smoothieware just copy a smoothie firmware.bin to the card like usual and power up the board.

Quote
sdavi

No, RRF does not show up as a storage device on the PC.

I've not see the MKS TFT32 before. From what I can see, it appears to be a standalone device that acts as a host ?

The firmware does not modify the bootloader. To load smoothieware just copy a smoothie firmware.bin to the card like usual and power up the board.

-Yes, I noticed. I was asking if it was planned. It is quite convenient as one can modify the config, macros, load print job easily from the PC. Not everyone wants to use the Ethernet and is it currently OK for this board ?

- Indeed, the TFT32 is just that, a bit clumsy but comes handy as it allows to prepare, monitor, start jobs standalone. Has a regular SD card easier to handle than the micro plus a USB stick reader. Usually sold as a bundle with the MKS SBASE.
I bought this for cheap. Wanted to try a 32bit controller without wasting my kid's inheritance

-Did that. May be I got unlucky. Will try with an other SD card.

---

"A comical prototype doesn't mean a dumb idea is possible" (Thunderf00t)

Quote
MKSA
-Yes, I noticed. I was asking if it was planned. It is quite convenient as one can modify the config, macros, load print job easily from the PC. Not everyone wants to use the Ethernet and is it currently OK for this board ?

- Indeed, the TFT32 is just that, a bit clumsy but comes handy as it allows to prepare, monitor, start jobs standalone. Has a regular SD card easier to handle than the micro plus a USB stick reader. Usually sold as a bundle with the MKS SBASE.
I bought this for cheap. Wanted to try a 32bit controller without wasting my kid's inheritance

-Did that. May be I got unlucky. Will try with an other SD card.

No I don't have any plans to implement MSD.

If the display uses UART, then the AUX serial in RRF is configured for the UART pins on the LPC. I've not actually tested the AUX interface, but i do use the UART (but as the main serial device) on my mbed board so I know the UART code does function correctly. According to RRF GCode Documentation M575 can be used to configure the serial device, so maybe something like M575 P1 B57600 S0 might work (i'm assuming the display doesn't support checksums?, and replacing with the baud rate it expects).

Also, RRF can be put into "marlin compatibility mode" by setting M555 P2 in the config.g which should be compatible with most host programs.

Quote
sdavi

If the display uses UART, then the AUX serial in RRF is configured for the UART pins on the LPC. I've not actually tested the AUX interface, but i do use the UART (but as the main serial device) on my mbed board so I know the UART code does function correctly. According to RRF GCode Documentation M575 can be used to configure the serial device, so maybe something like M575 P1 B57600 S0 might work (i'm assuming the display doesn't support checksums?, and replacing with the baud rate it expects).

Hi,
I put M575 P1 B115200 S0 in config.g (speed as In smoothiefirmawre no checksum), doesn't work

With P0 I can't connect via the USB anymore, so P0 is indeed for USB

Looking at the MKS schematic, the TFT is connected to TXD0, RXD0 (pin 98 P0[2], 99 P0[3])

Edited 2 time(s). Last edit at 12/12/2018 02:38PM by MKSA.

---

"A comical prototype doesn't mean a dumb idea is possible" (Thunderf00t)

Quote
MKSA
Hi,
I put M575 P1 B115200 S0 in config.g (speed as In smoothiefirmawre no checksum), doesn't work

With P0 I can't connect via the USB anymore, so P0 is indeed for USB

Looking at the MKS schematic, the TFT is connected to TXD0, RXD0 (pin 98 P0[2], 99 P0[3])

I hooked up my FTDI board to the UART today, and funnily enough there was a issue with the UART code in the lib i was using, looks like it was running at the wrong baud rate, i've swapped out the code that sets the baud rate with the mbed library version and that has fixed that.

However, unfortunately it doesn't help you with your TFT board as it appears as though the AUX serial in RRF only replies to the M408 command - it will accept and run other commands just not directly send back the response. So unless the TFT can talk "paneldue" (the json responses from M408) it doesn't look like it will work at this stage.

The aux port in RRF responds to the same commands as USB. The responses are only JSON if the command asks for JSON or is one that always responds with JSON. The main difference is that the aux port doesn't do Marlin emulation. In particular, it doesn't return "ok" after every response. If you want to change that, the relevant code is in function HandleReply in file Platform.cpp.

Edited 2 time(s). Last edit at 12/13/2018 08:38AM by dc42.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Quote
sdavi

I hooked up my FTDI board to the UART today, and funnily enough there was a issue with the UART code in the lib i was using, looks like it was running at the wrong baud rate, i've swapped out the code that sets the baud rate with the mbed library version and that has fixed that.

However, unfortunately it doesn't help you with your TFT board as it appears as though the AUX serial in RRF only replies to the M408 command - it will accept and run other commands just not directly send back the response. So unless the TFT can talk "paneldue" (the json responses from M408) it doesn't look like it will work at this stage.

Will the fixed MKSBASE ver be released soon here ?
[github.com]

PS: If the combo MKS SBASE TFT32 works with RRF, it could boost it. Not top notch hardware but dirt cheap and could be an incentive to go for something better later. Smoothieware is OK but not that much activity and new releases are said not to be able to run on MKS due to clock speed differences.

Edited 1 time(s). Last edit at 12/13/2018 05:43AM by MKSA.

---

"A comical prototype doesn't mean a dumb idea is possible" (Thunderf00t)

Quote
MKSA
Will the fixed MKSBASE ver be released soon here ?
[github.com]

PS: If the combo MKS SBASE TFT32 works with RRF, it could boost it. Not top notch hardware but dirt cheap and could be an incentive to go for something better later. Smoothieware is OK but not that much activity and new releases are said not to be able to run on MKS due to clock speed differences.

Yep, updated and uploaded to github.

Luckily, there wasn't much to change, all responses are now treated as a "raw" message so they get sent over the UART instead of being stored, plus the aux responses are now also going through the compatibility emulation in case the TFT needs the marlin style with the OK.

Hopefully that will get the TFT working.

Hi,
TFT is not yet working. Just tried different speed, (in config.g) not the Marlin emulation mode.

BTW, can these commands be issued on the Pronterface console or are they handled just at startup time ?

Too bad I don't have anything to analyze the traffic on these TX RX !

An other issue is that Pronterface works OK but Repetier acts strangely. I can connect, get status, set hotend, heater temp, read it but when I issue the home command, it answers gibberish and cn't communicate anymore ?
Can't say it was working with previous .bin, didn't try.

---

"A comical prototype doesn't mean a dumb idea is possible" (Thunderf00t)

Quote
MKSA
Hi,
TFT is not yet working. Just tried different speed, (in config.g) not the Marlin emulation mode.

BTW, can these commands be issued on the Pronterface console or are they handled just at startup time ?

Too bad I don't have anything to analyze the traffic on these TX RX !

An other issue is that Pronterface works OK but Repetier acts strangely. I can connect, get status, set hotend, heater temp, read it but when I issue the home command, it answers gibberish and cn't communicate anymore ?
Can't say it was working with previous .bin, didn't try.

Yep, those commands can be just run from the console no need to keep editing config.g and rebooting while testing, even changing the serial baud rate happens straight away.

I noticed the TFT has a config file called mks_config.txt ?? which appears to have a option to set firmware type to marlin, repetier or smoothieware. Setting that to marlin mode may help?

We can also see if commands are getting sent to RRF. M111 is used to enable/disable debug messages for the various modules. If you run M111 P3 S1 that will turn on debug for gcodes and it will print out debug info over the USB serial i.e. in pronterface etc. Then if you send a gcode over aux such as M105 you should see this debug message: "aux: M105".

Someone was having an issue before with repetierhost, as it was enabling debugging for everything (M111 S6) and causing a out of memory fault. Turning off that option in repetier should fix that.

Set the TFT for Marlin emul, serial stays 115200
Issued serial debug command via Pronterface, commands (home, set heat ...) sent from pronterface are indeed echoed back but when issued from the TFT, one, two char are echoed back. Funny but when pressing home a few time on the TFT, I can see a G, 8 , 2 , one char per command but erratic order. Looks like G28 is really sent ?????
I tried 57600 too. Same behavior.

On the MKS SBASE board schematic there are CTS and RTS but can't see where they connect on the processor, no mention if they are used or not ?

---

"A comical prototype doesn't mean a dumb idea is possible" (Thunderf00t)

Quote
MKSA
Set the TFT for Marlin emul, serial stays 115200
Issued serial debug command via Pronterface, commands (home, set heat ...) sent from pronterface are indeed echoed back but when issued from the TFT, one, two char are echoed back. Funny but when pressing home a few time on the TFT, I can see a G, 8 , 2 , one char per command but erratic order. Looks like G28 is really sent ?????
I tried 57600 too. Same behavior.

On the MKS SBASE board schematic there are CTS and RTS but can't see where they connect on the processor, no mention if they are used or not ?

That's helpful info thanks. I can now replicate that issue when i set my serial program to use "line mode", so I'll see if I can find out why its not receiving all the characters.

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.

@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.

Edited 1 time(s). Last edit at 12/16/2018 12:47PM by dc42.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Quote
dc42
@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 now have about 4.5K of RAM that's never been used when running networking on a 5 driver board.

Quote
sdavi
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.

OK, It works !
Thanks

---

"A comical prototype doesn't mean a dumb idea is possible" (Thunderf00t)

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 ISR (Move interrupt) and trying to take the usbMutex without using a take semaphore function ending in fromISR.

As a temporary workaround, discarding the message when called from within an interrupt resolves the issue. Although it is advisable for people to disable debugging in their Host Software unless trying to diagnose an issue.

@sdavi, thanks for that. My intention was that there are no debugPrintf calls from within ISRs. I think the culprit is the debugPrintf calls in Move::CartesianToMotorSteps, because that is called indirectly when a homing switch is triggered. In the next commit I'll either guard those calls with !inInterrupt() or I'll guard debugPrintf itself with !inInterrupt().

Edited 1 time(s). Last edit at 12/17/2018 09:39AM by dc42.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

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 defaults to running as a standard serial console. Messages will go though the compatibility emulation. If you want it to operate as it does in RepRapFirmware (PanelDue style) download the source code and change the NO_PANELDUE define in Pins_LPC.h to 0 and recompile.
• Extra 8 SPI cycles added to the SDCard commands to resolve certain SDCards failing to initialise.

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 Wifi on the MKS.

---

"A comical prototype doesn't mean a dumb idea is possible" (Thunderf00t)

Binaries updated to RRFv2.02RC6+.

I've just merged in the latest update by DC42 to fix that assertion fault.

Quote
MKSA
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 Wifi on the MKS.

The web interface (DWC) used with RRF is very good. You can upload gcodes straight to the SDCard and start a print, edit files on the sdcard directly within the browser, jog the axes etc etc. The networking works well for me, I haven't changed anything much since the initial v2 port. There is an issue when trying to run certain CGodes namely M503, that have large responses and can make the webpage stop responding etc as it uses a lot of buffers, however, M503 over network isn't needed as you can view and edit the files directly in DWC.

At the moment I'm experimenting with connecting a cheap ESP32 to offload all the networking (also freeing some memory on the LPC) and to give wifi access to my smoothieboard.

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 on the MKS only one jumper to select 1/16 or 1/32 that affects ALL drivers. For the extruder I would like to try different microsteps.

---

"A comical prototype doesn't mean a dumb idea is possible" (Thunderf00t)

Quote
MKSA
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 on the MKS only one jumper to select 1/16 or 1/32 that affects ALL drivers. For the extruder I would like to try different microsteps.

For the LPC port, boards that can support software current control, the vref is set using the conversion factor defined in the variant header file by the variable "digipotFactor" - that is a fixed value for the board (based on the smoothie config for the MKSSBase it seems to be the same as Smoothieboard which is the value I used). You can just use M906 to set the desired current without worrying about formulas etc.

As for *M350, it has no effect when run on these boards since microstepping (if configurable) is set via hardware jumpers/solder pads. If you change the microstepping jumper you just need to update the steps per mm for the axes.

The 8825 drivers do need to be properly configured with M569 in the config.g as they require longer pulses to function correctly, there was a table earlier in this thread that has some common driver settings. Pulse settings are passed using the T param of M569. This is the setting for drive 0 I used on my AzteegX5 which also has 8825 drivers: M569 P0 S0 T1.9:1.9:0.65:0.65

Quote
sdavi

Quote
MKSA
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 on the MKS only one jumper to select 1/16 or 1/32 that affects ALL drivers. For the extruder I would like to try different microsteps.

For the LPC port, boards that can support software current control, the vref is set using the conversion factor defined in the variant header file by the variable "digipotFactor" - that is a fixed value for the board (based on the smoothie config for the MKSSBase it seems to be the same as Smoothieboard which is the value I used). You can just use M906 to set the desired current without worrying about formulas etc.

As for *M350, it has no effect when run on these boards since microstepping (if configurable) is set via hardware jumpers/solder pads. If you change the microstepping jumper you just need to update the steps per mm for the axes.

The 8825 drivers do need to be properly configured with M569 in the config.g as they require longer pulses to function correctly, there was a table earlier in this thread that has some common driver settings. Pulse settings are passed using the T param of M569. This is the setting for drive 0 I used on my AzteegX5 which also has 8825 drivers: M569 P0 S0 T1.9:1.9:0.65:0.65

- 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 doc, I have some doubt. Note it could be due to the "idle" mode and therefore reduced current.
Could you give me the formula you use ? So I don't have to look in the code for it and the variable digipotFactor ?

- M350, So I suppose you totally ignore this command, which makes sense. I was just checking.

- I know about the different pulse settings and defined them OK. Fact is, the more I play, the more I realize these 8825 suck.
Thanks.

Edited 1 time(s). Last edit at 12/20/2018 12:43PM by MKSA.

---

"A comical prototype doesn't mean a dumb idea is possible" (Thunderf00t)

Quote
MKSA
- 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 doc, I have some doubt. Note it could be due to the "idle" mode and therefore reduced current.
Could you give me the formula you use ? So I don't have to look in the code for it and the variable digipotFactor ?

- M350, So I suppose you totally ignore this command, which makes sense. I was just checking.

- I know about the different pulse settings and defined them OK. Fact is, the more I play, the more I realize these 8825 suck.
Thanks.

The digital pot (at least on my boards) is the mcp4451, and in code, the wiper tap value is simply set to (current*factor). I just used the factor values that smoothie used since they were already calculated My azteeg board has the vref pins broken out to a pad conveniently located next to each stepper header so i just used that to check against the values when running smoothie to see if that part of port was working so I've never looked into the actual formula to calculate it.

The only schematic I came across for the MKS was for Version 1.2, and it didn't have any values for the resistors etc. I guess you'll have to read the resistors values off the board, look up the datasheets and determine the wiper tap that the digital pot needs to be set to in order to create the correct vref for the driver and find the corresponding factor. You'll need to also check the mcp4451 chip on board too as it has 4 different resistance versions according to the datasheet.

Edited 1 time(s). Last edit at 12/20/2018 07:51PM by sdavi.