Re: LPC port of RepRapFirmware February 04, 2019 03:24AM |
Registered: 10 years ago Posts: 341 |
Quote
dot_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 the display can't run very fast without artifacts. The same display runs fine on the AZSMZ Mini and BIQU SKR.
I have been playing with memory settings trying to make the network more reliable. it is working fairly well with NumHttpResponders = 1 and NumHttpSockets = 1 but goes to lunch after 5-10 minutes. It still responds to pings but the web server is MIA. The changes to the memory and network settings are in my default branch: [github.com]
Re: LPC port of RepRapFirmware February 04, 2019 09:28AM |
Registered: 9 years ago Posts: 14,664 |
Quote
dot_bob
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 the display can't run very fast without artifacts.
Re: LPC port of RepRapFirmware February 04, 2019 11:38AM |
Registered: 6 years ago Posts: 1,007 |
Quote
dc42
Quote
dot_bob
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 the display can't run very fast without artifacts.
My guess is that the SBASE is sending 3.3v SPI signals to the display, however the datasheet for the ST7920 chip used in the RRD display specifies minimum high signal level of 0.7 * Vcc, which for the 5V RRD display is 3.6V. Preferably, use 5V level shifters on at least the SPI clock and data signals to the display. I've heard reports that these displays sometimes work with 3.3V signal levels if the SPI clock speed is reduced. In RepRapFirmware 2.03beta1 I've added a F parameter to the M918 display so that the display SPI frequency can be altered without rebuilding the firmware.
Re: LPC port of RepRapFirmware February 04, 2019 12:30PM |
Registered: 9 years ago Posts: 14,664 |
Quote
MKSA
From the schematic, it is in 5V logic. They use SN74LVC1T45 level shifter. Note I don't use this ext port.
Re: LPC port of RepRapFirmware February 04, 2019 02:07PM |
Registered: 6 years ago Posts: 1,007 |
Quote
dc42
Quote
MKSA
From the schematic, it is in 5V logic. They use SN74LVC1T45 level shifter. Note I don't use this ext port.
What - there is actually a schematic for the MKS SBASE? Where?
If it does use 5V logic levels for the SPI drive to the display, then it should work at 2MHz SPI clock if the cables are reasonably short.
Re: LPC port of RepRapFirmware February 11, 2019 11:34PM |
Registered: 10 years ago Posts: 341 |
Re: LPC port of RepRapFirmware February 15, 2019 06:55AM |
Registered: 6 years ago Posts: 1,007 |
Re: LPC port of RepRapFirmware February 16, 2019 05:47AM |
Registered: 10 years ago Posts: 341 |
Quote
MKSA
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.
Re: LPC port of RepRapFirmware February 16, 2019 09:16AM |
Registered: 9 years ago Posts: 14,664 |
Quote
sdavi
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 least stop the command M111 S6 turning on debugging for all modules.
Re: LPC port of RepRapFirmware February 18, 2019 10:24PM |
Registered: 10 years ago Posts: 341 |
Re: LPC port of RepRapFirmware February 19, 2019 04:48AM |
Registered: 9 years ago Posts: 14,664 |
Re: LPC port of RepRapFirmware February 25, 2019 04:33PM |
Registered: 5 years ago Posts: 10 |
Re: LPC port of RepRapFirmware February 26, 2019 01:54AM |
Registered: 10 years ago Posts: 341 |
Quote
dot_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 definitions in the board.txt.
Ethernet functionality is more reliable. I was able to leave the board running overnight and not have any lost packets or disconnects.
I did have a show stopper though. If I started a print a few seconds into the first layer of a print I would get a hard fault reset. This seemed to happen when printing via USB tethered to S3D, or printing the gcode file from the web ui. It seemed to be failing on simple moves while extruding. I disabled display support and recompiled to see if there was any difference and had the same result. I didn't have time to dig any deeper.
Re: LPC port of RepRapFirmware February 26, 2019 09:10PM |
Registered: 5 years ago Posts: 10 |
Re: LPC port of RepRapFirmware February 27, 2019 11:03PM |
Registered: 10 years ago Posts: 341 |
#0 HardFault_Handler () #1 < signal handler called > #2 DDA:: Start #3 Move:: StartNextMove #4 Move:: TryStartNextMove #5 DDA:: Step #6 Move:: Interrupt #7 TIMER0_IRQHandler()
Re: LPC port of RepRapFirmware February 28, 2019 02:22AM |
Registered: 9 years ago Posts: 14,664 |
Re: LPC port of RepRapFirmware March 01, 2019 12:17AM |
Registered: 5 years ago Posts: 10 |
Re: LPC port of RepRapFirmware March 01, 2019 02:39AM |
Registered: 6 years ago Posts: 1,007 |
Re: LPC port of RepRapFirmware March 01, 2019 03:39AM |
Registered: 10 years ago Posts: 341 |
Re: LPC port of RepRapFirmware March 02, 2019 12:19PM |
Registered: 5 years ago Posts: 10 |
Quote
sdavi
Looks like the main cause was "updating" the network driver memory allocation to match the other drivers in +tcp, so i've reverted back to the previous version.
Ive run a couple of different test gcodes through and so far no issues.
Updated Binary
Re: LPC port of RepRapFirmware March 03, 2019 01:04AM |
Registered: 10 years ago Posts: 341 |
Quote
dot_bob
Your binary is working on everything I throw at it so far. I keep you up to date if I see anything strange.
Re: LPC port of RepRapFirmware March 28, 2019 03:22AM |
Registered: 6 years ago Posts: 21 |
Re: LPC port of RepRapFirmware March 29, 2019 04:17AM |
Registered: 6 years ago Posts: 1,007 |
Re: LPC port of RepRapFirmware March 29, 2019 06:22AM |
Registered: 10 years ago Posts: 341 |
Quote
svs072477
Hi, you wrote that you wanted to experiment with ESP 32. Is anything working?
Re: LPC port of RepRapFirmware April 01, 2019 12:29AM |
Registered: 10 years ago Posts: 341 |
Re: LPC port of RepRapFirmware April 25, 2019 10:59PM |
Registered: 8 years ago Posts: 10 |
Quote
JoVo
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.
Re: LPC port of RepRapFirmware April 28, 2019 05:23AM |
Registered: 10 years ago Posts: 341 |
Quote
tripio2000
Quote
JoVo
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.
Hello, is there any solution to this problem? my board (MKS SBASE 1.3) has the same issue. Thanks in advance
Re: LPC port of RepRapFirmware April 28, 2019 10:13AM |
Registered: 7 years ago Posts: 19 |
Re: LPC port of RepRapFirmware May 01, 2019 06:20AM |
Registered: 8 years ago Posts: 10 |
Re: LPC port of RepRapFirmware May 02, 2019 04:17AM |
Registered: 9 years ago Posts: 14,664 |
Quote
sdavi
Yeah, it is getting close to working I think, only work on it now and again though. I've basically taken the whole Networking folder from RepRapFirmware and have it running on the ESP32 (only HTTP at this point). So most of the transfers between the LPC<->ESP (over SPI) are JSON status updates and File download/uploads from/to the SD Card and all the networking is handled by the ESP. This moves all the large memory buffers to the ESP and freeing up lot of memory on the LPC board - only requiring the memory buffers for the SPI transfers. The wifi, loading files, getting json status updates etc is currently working, so its slowly getting there.