Maybe it will work with other pins. Think for SW_SPI every pin should work. I can live without SD card but I need SPI for MAX33xx K Type Sensor. I will try it tomorrow
Hmmm ok, think 51 is mosi and should work. Because u8g_InitSPI its called with UI_DISPLAY_ENABLE_PIN but inside the method its called U8G_PI_MOSI. And UI_DISPLAY_D4_PIN seems to be SCK and is set to Pin 52 which is also right. Didn't know that the LCD comunicate also over SPI. In that case the pins are sure right because the display works :-D
In short, I have no idea why it is not working.
I tested a MAX31855 connecting to SCK (D52) and MISO(D50) and CS(D17) with TEMP_PIN set to D17 and Thermistor type 102 but is also not work.
Could you try dev version? I recently added some fixes from the original library to improve compatibility with old sd cards. From teh changes it seems that timings for reading commands were changed.
you use ramps-fd ? where and on which connector did you connect SD?
I'm searching for a solution with more power than an Arduino Uno. (problems with 120mm/sec speed and circles)
So I first tried a ramps-fd with: https://www.geeetech.com/3d-printer-lcd-panel-adapter-for-rampsfd-p-905.html and an RepRap 12864 Full Graphics Display. That worked but I never tested / used the SD card but display worked. But I switched to Smart RAMPS because the Mosfets on the ramps-fd where low active. Which means that that the heaters and heatbed where powered until the software could start and stop it. Repetier is rock solid but that sounds very dangerous in my eyes.
Ramps-fd 2.0 use active high mosfets and is secure but this version is no where buyable. All ramps-fd that I found in ali or bay or others where version 1 boards with this "bug".
If you want, I can test if ramps-fd works with display adapter and
with correct pin numbers should make sd card use software spi.
The strange thing is that it worked without software spi in 0.92. Read that it worked, not proofed till now! And there is a git clone with a change request from cxcandy with definitions for AZSMZ 12864 .
The smart ramps hasn't changed. The hardware spi was never connected to the shield. It used in the past also 50,51,52 which are normal pins that are not hardware spi pins.
I think software spi is only spi with 3 digital pins. You can choose every pin and generate clock and miso/mosi pins out of them. I will send you tomorrow an smart ramps and an ramps-fd to Willich. Funny, didn't know that repetier hq is only 300 kilometers away :-D
Error while detecting libraries included by C:\Users\dominik\AppData\Local\Temp\arduino_build_902038\sketch\SDCard.cpp while compiling and yes, I have the same error compiling trunk/dev and 1.0.3
Its hidden between all the compiler output and its no compile break. Has this something to do with the problem ?
Thanks for sending the ramps-fd. If you have also include the max33.. sensor. I have none and as I understand the problem is having both running, right? I mean they have a old 0.92.8 version whcih they made a picture of so I guess that should work just without the sensor.
Regarding the error message - that is strange as we do not use external libraries to be detected for sd card. We use sdfat library in a modified way that is included in the sources.
Yes, I added also a MAX31855. But no, the MAX31855 doesn't work with Smart Ramps. Also without Display/SD connected. No error but reads only 0. For me that is more a problem because I do not use the SD.
I'm not sure if the image alone says that it will work for ali express china products :-D The problem is that Smart RAMPS is usable also with arduino MEGA. In that case the pins are mapped to the hardware spi pins in the mega. But not if you use an Arduino due. Maybe in that case it never worked. Not sure.
Yes, SPI pins might not even be on the pins where they are for RAMPS board plus sd card has a 5-3.3V level shifter on smart ramps. So what happens there if you start only with 3.3V?
Just looked into MAX31855 datasheet and that seems to at least work directly with 3.3V so no level shifter required here.
I have a AZSMZ 12864 LCD connected. Its designed for 3,3 volt. Can't remember if there was a level shifter. I sent you also the AZSMZ 12864 LCD and ordered a new from from china and I can't find a boardlayout for the display. The smart ramps itself I can't see a typical level shifter chip. The only chip is the eeprom, the rest smd diodes resistors. When its a level shifter with diodes it should with 3,3 Volt. But i'm software developer and early electric beginer :-D
RRD and the MAX chips over SPI will maybe never work.
From smoothie site: "Because the RRD GLCD does not implement SPI correctly, it has to be alone on it's SPI port. This means you won't be able to use SPI thermocouples and the RRDÂ GLCD together on the same board, unfortunately "
The I2C VCC connector (+ under Pin 20) is 3,3 volt on the smart ramps. Other than the diagram on reprap shows. I used this VCC and ground for the MAX3xx. All other VCCs are 5 volt.
But if this is true that SPI is unusable for other SPI devices because of the wrong impl. of the RRD, than a software SPI is maybe for others also interesting because then they can use for other things that are SPI devices a second software SPI instance.
The RRD use software SPI for teh display and hardware SPI for the sd card. For the MAX a software SPI solution would also work if implemented. Only problem is that I need to pass MISO and CLK pin in addition somehow. So adding some softwrae Max... means adding 20 or more parameter:-(
I'm using SmartRamps with AZSMZ 12864 LCD connected and have been able to get the SD Card working with latest development branch 1.0.3 using the recent Soft SPI implementation. I've made the following changes to my local code:
In DisplayList.h add the following under Feature Controller CONTROLLER_AZSMZ_12864:
You'll need to make sure your downloading the very latest source from GitHub which has Repetier.h updated with this function: SdFatSoftSpi<SD_SOFT_MISO_PIN, SD_SOFT_MOSI_PIN, SD_SOFT_SCK_PIN> fat;
For some reason when downloading through the Repetier configurator page (even after switching to dev 1.0.x) I wasn't getting the very latest Repetier.h in the firmware download.
I still haven't been able to get the display working properly but I think I've broken the LCD as even going back to 0.92 (which did work once) it's still just the backlight...
Yes, that worked quite well. Still have to check why I can only see files when I insert a sd card and not when it was inserted, but that seems a internal error. Your solution is at least online in dev tree. Will see how to fix the file selection my self.
Great, thanks for that. I saw the commit into dev tree last night and tested on my machine - all working perfectly and no issues with SD card either. Files are visible when the machine is started with SD card inserted and when re-inserting card. Test print from SD card went through fine as well. The LCD issue I was having was due to dry solder joints on the LCD panel. After a quick reflow on all the joints the LCD screen has come back to life.
Edit: one other comment - the encoder a/b was reversed in latest commit. Compared to my other Ramps 1.4 controller it's going in the "wrong" direction. Might need to change the UI menu direction setting or reverse the pins in the display pin settings
Yes, I revered direction as it was going in wrong direction to my standards on my device:-) Clockwise turns increase or go down in menu is the default.
Also I like to hear you can select prints when starting with sd card, I can't:-( Tested with 2 different cards I can read when inserting. But it is also random. Sometimes I loose files when scrolling and more scrolling brings them back. So maybe a bad soldering/contact causing all the trouble on my side. My other displays also do not have the problem. So I guess I can ignore the problem then. Thanks for testing.
I did some further testing on the AZSMZ display last night and started running into some SD card errors too. I was able to print but with some pauses during the print after which the print continued with no intervention. The more I look into the AZSMZ board the more issues that seem to arise unfortunately. My quick reflow job was only good for a few cycles and then it's failed again. Given my issues are different to yours but both occur randomly it makes me think that the issues are in the quality of the PCB or vias. With some flexing of the board I could temporarily make the screen come back to life or get through a full length SD card print with no issues. The display board appears to be of a lower quality to the Smart Ramps board itself. The other issue is potentially a clash or overlap between the software SPI pins for the SD card and LCD display as the are both sharing. Typically hardware SPI would have used CS to resolve but not sure how the software SPIs relate to each other.
All this then motivated me to go back to the RepRapDiscount Full Graphic Smart Controller (display type 11) that I had in the cupboard and work out how to connect to Smart Ramps as there are no pre-defined pins for that configuration. The good thing with this controller is that the SPI connections for LCD and SD card are completely separate. The Exp1 and Exp2 connections on the display are simply connected into Aux-2 and Aux-3 on the Smart Ramps board (there are no orientation lugs on the the Aux-2 & 3 headers and reversing direction didn't cause any damage so just flip the orientation of the connector until the display backlight comes on). After working through the schematics for both boards I have the display and SD card working with the details as follows.
Under the DisplayList.h I have added a new board configuration for FEATURE_CONTROLLER == CONTROLLER_SMARTRAMPS:
#define SDSS 49 The SD card SPI connections are then set in the Smart Ramps board pin definition: // Smart RAMPS has no hardware SPI so we need to use software spi instead
My question is how should the SoftSPI SD pins be set as they should really be under the display definition rather than the board pins given that SoftSPI pins can vary between displays. But when I set the the SD_SOFT pin definitions in DisplayList.h there are SD fat errors on compile and the card stops working. If you think this configuration would be of use to others please feel free to add into the dev source.
Ok, have updated dev version to contain your settings. I can see and control display and it also registers if sd card is inserted, but I see no files. Did you see files for sd card?
The trick to handle both displays is to define sd card settings in ui.h around line 460.
Thanks for the clarification - ui.h makes sense now! I have tripled checked my setup and definitely can see all the files and print from SD with no issues. I initially expected some issues due to 3.3v on Due vs 5v on Mega2560 but the display and card worked as expected. I know the display has a level shifter integrated which I thought my cause issues. I have tested in dry run mode with all logging turned on to identify any read errors and all went through smoothly. Test prints also went through as expected. I will check out the commits later today and re-download from source to test for any issues between my 'hack job' and your commits.
Yes, also had doubts from the spi level shifter. MY display is one of the first ever produced so maybe they changed chips later. Anyhow since it worked for you with your hack it should also work with new version if not any code changes the pins back to different values. Thanks for retesting.
Comments
Maybe this will not work because at least D51 like mentioned above is used as UI_DISPLAY_ENABLE_PIN
Out of DisplayList.h:
I can live without SD card but I need SPI for MAX33xx K Type Sensor.
I will try it tomorrow
Because u8g_InitSPI its called with UI_DISPLAY_ENABLE_PIN but inside the method its called U8G_PI_MOSI.
And UI_DISPLAY_D4_PIN seems to be SCK and is set to Pin 52 which is also right.
Didn't know that the LCD comunicate also over SPI.
In that case the pins are sure right because the display works :-D
In short, I have no idea why it is not working.
I tested a MAX31855 connecting to SCK (D52) and MISO(D50) and CS(D17) with TEMP_PIN set to D17 and Thermistor type 102 but is also not work.
Yes, its a old Sandisc 512 MB card. I can test with a newer if you want.
I found DUE_SOFTWARE_SPI in the code. Can this help ?
I have added software spi for sd card now also I have no device to test it.
#define ENABLE_SOFTWARE_SPI_CLASS 1
#define SD_SOFT_MISO_PIN 10
#define SD_SOFT_MOSI_PIN 11
#define SD_SOFT_SCK_PIN 12
with correct pin numbers should make sd card use software spi.
The strange thing is that it worked without software spi in 0.92.
Read that it worked, not proofed till now!
And there is a git clone with a change request from cxcandy with definitions for AZSMZ 12864 .
The smart ramps hasn't changed. The hardware spi was never connected to the shield. It used in the past also 50,51,52 which are normal pins that are not hardware spi pins.
I think software spi is only spi with 3 digital pins. You can choose every pin and generate clock and miso/mosi pins out of them.
I will send you tomorrow an smart ramps and an ramps-fd to Willich. Funny, didn't know that repetier hq is only 300 kilometers away :-D
There is also the source code that should work. Will test it this weekenend.
https://de.aliexpress.com/item/SMART-Ramps-AZSMZ-12864-LCD-For-Arduino-Due-Like-RAMPS-FD-or-RADDS-3D-print-control/32836384483.html?spm=a2g0x.10010108.1000016.1.22ea272cXH6997&isOrigTitle=true
also not works. Seems like a patched 0.92 BUT:
This time I saw:
while compiling and yes, I have the same error compiling trunk/dev and 1.0.3
Its hidden between all the compiler output and its no compile break.
Has this something to do with the problem ?
Regarding the error message - that is strange as we do not use external libraries to be detected for sd card. We use sdfat library in a modified way that is included in the sources.
No error but reads only 0. For me that is more a problem because I do not use the SD.
The problem is that Smart RAMPS is usable also with arduino MEGA. In that case the pins are mapped to the hardware spi pins in the mega. But not if you use an Arduino due. Maybe in that case it never worked. Not sure.
Just looked into MAX31855 datasheet and that seems to at least work directly with 3.3V so no level shifter required here.
The smart ramps itself I can't see a typical level shifter chip. The only chip is the eeprom, the rest smd diodes resistors. When its a level shifter with diodes it should with 3,3 Volt. But i'm software developer and early electric beginer :-D
RRD and the MAX chips over SPI will maybe never work.
From smoothie site:
"Because the RRD GLCD does not implement SPI correctly, it has to be alone on it's SPI port. This means you won't be able to use SPI thermocouples and the RRDÂ GLCD together on the same board, unfortunately "
The I2C VCC connector (+ under Pin 20) is 3,3 volt on the smart ramps. Other than the diagram on reprap shows. I used this VCC and ground for the MAX3xx. All other VCCs are 5 volt.
For the MAX a software SPI solution would also work if implemented. Only problem is that I need to pass MISO and CLK pin in addition somehow. So adding some softwrae Max... means adding 20 or more parameter:-(
In DisplayList.h add the following under Feature Controller CONTROLLER_AZSMZ_12864:
In Pins.h add the following under Motherboard 408 / 413:
You'll need to make sure your downloading the very latest source from GitHub which has Repetier.h updated with this function: SdFatSoftSpi<SD_SOFT_MISO_PIN, SD_SOFT_MOSI_PIN, SD_SOFT_SCK_PIN> fat;
For some reason when downloading through the Repetier configurator page (even after switching to dev 1.0.x) I wasn't getting the very latest Repetier.h in the firmware download.
I still haven't been able to get the display working properly but I think I've broken the LCD as even going back to 0.92 (which did work once) it's still just the backlight...
Edit: one other comment - the encoder a/b was reversed in latest commit. Compared to my other Ramps 1.4 controller it's going in the "wrong" direction. Might need to change the UI menu direction setting or reverse the pins in the display pin settings
Also I like to hear you can select prints when starting with sd card, I can't:-( Tested with 2 different cards I can read when inserting. But it is also random. Sometimes I loose files when scrolling and more scrolling brings them back. So maybe a bad soldering/contact causing all the trouble on my side. My other displays also do not have the problem. So I guess I can ignore the problem then. Thanks for testing.
All this then motivated me to go back to the RepRapDiscount Full Graphic Smart Controller (display type 11) that I had in the cupboard and work out how to connect to Smart Ramps as there are no pre-defined pins for that configuration. The good thing with this controller is that the SPI connections for LCD and SD card are completely separate. The Exp1 and Exp2 connections on the display are simply connected into Aux-2 and Aux-3 on the Smart Ramps board (there are no orientation lugs on the the Aux-2 & 3 headers and reversing direction didn't cause any damage so just flip the orientation of the connector until the display backlight comes on). After working through the schematics for both boards I have the display and SD card working with the details as follows.
Under the DisplayList.h I have added a new board configuration for FEATURE_CONTROLLER == CONTROLLER_SMARTRAMPS:
The SD card SPI connections are then set in the Smart Ramps board pin definition:
// Smart RAMPS has no hardware SPI so we need to use software spi instead
My question is how should the SoftSPI SD pins be set as they should really be under the display definition rather than the board pins given that SoftSPI pins can vary between displays. But when I set the the SD_SOFT pin definitions in DisplayList.h there are SD fat errors on compile and the card stops working.
If you think this configuration would be of use to others please feel free to add into the dev source.
The trick to handle both displays is to define sd card settings in ui.h around line 460.
Thanks for retesting.