Change encoder function based on LCD case

Hi Team,

I'm starting to hack the box 1 code. My goal is to add a second page of options on the LCD screen, and have the encoders control those parameters as well. I want to change the NEXT/LAST buttons to cycle through the LCD screens, but keep the 3rd button as Fine/Coarse. Currently I've got the display pretty well sorted, but I don't know how to implemented the additional encoder functions.

Question 1

I'm using cases to define what goes onto the LCD screen. I think that it is in these cases that I want to define/tie encoder function to the parameters displayed on screen. I'm not sure if I leave a pointer here and declare them in setup the way pan/tilt encoders are in the original sketch, or if I move all of the pin talk up to the display cases function? I think the pin assignments have to stay in the setup, so that means I probably need to write a new function that reassigns the encoders? Would I then plug that function into my switch cases?

Question 2

I've written Zoom and Intensity encoders into all the functions, but haven't told the arduino where to look for that input. When I plug into my nomad I expect the pan/tilt functionality to work, as well as the display page scrolling(both do). I don't expect Zoom/Intens to work, but I'm still receiving ticks from them in the diagnostics tab. If they are not assigned encoders yet, what is sending those ticks? (admittedly, this is a smaller problem that I imagine will go away once I assign encoders, I'm just curious since this outcome was unexpected.)

Any tips would be appreciated, even if it's just pointing me to an example that deals with reassigning buttons or encoders mid sketch. I'm pretty good at reworking code to fit my needs, but still mostly a beginner.

Side note: I broke a pin off one of my buttons and only have 2 functioning at the moment, so in my current code there's only an option to page forward through LCD screens. The functionality works though, so adding a second button when I have another working one should be easy. Just wanted to mention it in case you stumble on an irregularity in my code.

my code:

github.com/.../2ndEncoderPage_v1.ino

Parents Reply Children
  • The issue isn't pins it's the serial connection, I think. Admittedly this is reaching the limit of my understanding, but it was suggested in another post that because of how the serial is setup on the Uno it isn't able to map multiple functions to one encoder. It was also mentioned that a Leonardo was able to handle multiple pages per encoder. Since the Leo is cheaper than a teensy I went with the Leo, but am running into issues with Eos recognizing it. 

    Long story longer - do you happen to know if the mega will support multiple encoder pages, or will I have to hard link functions to encoders? I'm happy to go with a teensy, but if megas are cheaper then that would be a good option for the tool bag.

  • The problem is the USB connection of UNO/MEGA, it is to slow to handle the connection to the console,
    also the ring buffer is a problem. Personally I've never used a Micro/Leonardo on a console only for Nomad. A Teensy 3.5 will be the best choose because the chip is fast enough to handle the connection.
    On a beta version of the Eos software it was possible to connect the serial with a lower speed like 9600 baud, which also helps, but it doesn't work any more on Nomad.

  • I've currently got an 18 encoder with 18 button device running on a mega 2560 with no issues.  The teensy do work better especially when you are moving multiple encoders at the same time but the Uno and mega can handle many of the simpler setups people want to do. The micro, leonardo, and many clones that need custom drivers to do usb serial is that the console either doesn't have the drivers or the console software isn't looking for them to connect.  

    I made a list of micro controller models and their response with the ETC test sketch on ETC's light hack GitHub.  These were all made connecting to a console and documenting whether the console attempted to connect and if it did attempt did the micro controller send a response back.  After doing those tests the underlying Osc library was updated which made a few additional boards work properly.

  • See your trick, you filter out the eos/out messages and subscribe only the messages you actual need. I will give it a try.