Encoder stop working after print

luxarts

I'm printing from SD. The encoder works great, the display and the SD too. When the print finishes the rotary action of encoder stop working but the button works fine. If I reset the board it start to work again. I dont know if it's a bug in the firmware or a configuration problem. I didn't found anything similar in the forum or github.

I'm using the firmware 1.0.0 generated with the Configuration Tool web and modified the settings for display, encoder and buttons.

This is part of my uiconfig.h

void uiInitKeys() {
#if UI_HAS_KEYS!=0
UI_KEYS_INIT_CLICKENCODER_LOW(31,33); // click encoder on pins 31 and 33. Phase is connected with gnd for signals.
UI_KEYS_INIT_BUTTON_LOW(35); // push button, connects gnd to pin
UI_KEYS_INIT_BUTTON_LOW(41); // push button, connects gnd to pin
#endif
}
void uiCheckKeys(uint16_t &action) {
#if UI_HAS_KEYS!=0
UI_KEYS_CLICKENCODER_LOW_REV(31,33); // click encoder on pins 31 and 33. Phase is connected with gnd for signals.
UI_KEYS_BUTTON_LOW(35,UI_ACTION_OK); // push button, connects gnd to pin
UI_KEYS_BUTTON_LOW(41,UI_ACTION_EMERGENCY_STOP); // push button, connects gnd to pin
#endif
}

Thanks!

Repetier

Never have seen or heard about that problem.
The only reason I can see is that one of the encoder pins or both are not set as input anymore or pullup is not enabled for it.

Are you printing with server or from sd card? In first case there is not much for firmware to do as it just executes commands. Then it would make sense that one of the commands near end causes this to happen and if you can find out which command it should be easy to find the reason. But even from sd card it just stops reading the file and there is no apparent reason to do such a thing.

luxarts

I'll search in the files if another thing its using pins 31 and 33. I forgot to say that I'm using the ARM version of firmware in a DUE board with Smart RAMPS and RepRapDiscount Full Graphic Smart Controller.
Also, the scroll in between files on SD it's slow. Tried 3 SD cards of different sizes but the same problem. I don't know if it's a SPI low speed problem (as DUE have to use software SPI and maybe it's slower than hardware) or a encoder speed multiplier or something like that. Another problem it's that the save on EEPROM (on SD card) in display doesn't save anything but from Repetier Host it does.

Edit: I found the problem. My GCode had a line at end with "M42 P33 S255" because thes case has the lights in that pin. Anyways the SD card problem is still there. I'll try to figure out how to resolve it.

Thanks for the reply!

Repetier

These graphic displays take around 0.1s to update so you can only scroll 10 files per second. Maybe a bit more on due.

On arm it can happen that some pins are used also for special functions. That is why a thought finding the gcode that makes it unfunctional should help finding which function changes pin definition. Normally pin direction is only set during setup, so I even wonder why it happens so late. Temperatures, heaters etc are already initalized and it was still working, so what could start using the pin.

luxarts

But I can scroll like 1 file per second. It's extremly slow compared with the AVR version on an Atmega2560 (same display, of course).

Repetier

Can you scroll faster in other menus? I just ask to see if the display is slow or sd reading. Fact is for each sd list update it needs to read the full directory so if you have many files it gets slower.

luxarts

Yes, in any other menus I can scroll faster. I tried with a few files in sd card and its a bit faster but remains slower than Atmega2560. I think the difference its because software SPI can't go fast as hardware SPI, but this surprise me because the DUE has a 5 times faster CPU.
The question is, I'm the only one with this problem? If not, I'll open an issue in the repository and try to fix it.
By the way, the encoder problem it's because if the pin is an input (signals A and B of encoder) with internal pull-up and you write a 0 in that pin, the pull-up will be disabled.

pinMode(31,INPUT_PULLUP);//Input with pull-up enabled //That it's the same to pinMode(31,INPUT);//Pin as input digitalWrite(31,HIGH);//Enable pull-up

I hope this help someone.

Repetier

Where is that pin mode problem? Could not detect it.

ui.h

#define UI_KEYS_INIT_CLICKENCODER_LOW(pinA,pinB) SET_INPUT(pinA);SET_INPUT(pinB); PULLUP(pinA,HIGH);PULLUP(pinB,HIGH);In HAL.h you see

#define PULLUP(IO, v) </div>

{ ::pinMode(IO, (v != LOW ? INPUT_PULLUP : INPUT)); }

which would enable pullup just as required.

Just tested sd card scrolling and it was fast, but I use hardware SPI for it, so that might make a difference. Guess for going through directory you need to read much sectors, especially if it was long. Not sure if it reduces to 1 sector if all files are deleted since I already know that deleting is just marking the directory entry as deleted.
Have you tried with the sd card reader on the RADDS board directly? That can use hardware SPI as well.

luxarts

The pin mode problem was in my slicer. At the end of the gcode my slicer adds "M42 P31 S255" (because I was using that pin for the lights of the case in a previous version) which means digitalWrite(31,LOW). So if the pin 31 was in input mode, when you set the pin to LOW the internal pull-up will be disabled and the encoder stop working. It's not a bug in the firmware but if you want to prevent it you can add a condition to M42 commad to check if it's an output.

I didn't knew that Arduino DUE has hardware SPI. As I said, I'm using a RAMPS 1.4 modified and the SPI pins of SD cards connect to the SPI pins in Arduino Mega 2560 so I have to re-wire the conections and check if hardware SPI solves my problem. Where are the SPI pins in DUE?

Thanks!

Repetier

Ok, the explains why I do not find the code:-)

https://forum.arduino.cc/index.php?topic=132130.0<br/><br/>shows the pinout.

luxarts

Oh, the header in the middle. I'll try to connect the SD card to it.
Thanks!

Repetier

Default radds config activates this, but lcd config can overwrite to use an other one. There can only be one sd reader working.

luxarts

So I have to redefine the pins in the pins.h and displaylist.h, right?

Repetier

pins.h has pins set for radds sd card. You would need displaylis to not change them.