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
  • I stumbled on sstaub's multi-parameter box and tried uploading it through platformIO as recommended here(https://community.etcconnect.com/etclabs/f/lighthack/29787/would-it-be-possible-to-have-the-encoders-control-the-intensity-and-color-instead-of-pan-tilt). Now I have all the parameters, but only one of my encoders is working. I tried reloading the original box src to check if it was a hardware issue, but with that sketch the second encoder functioned correctly, so the issue is caused by the new code. In the comment chain sstaub mentions the UNO has a slow/low USB capability, I think this is probably the culprit since the code is reported to work on a teensy.

    I'm not sure how to troubleshoot this. When I checked in the diagnostic tab for incoming OSC the second encoder wasn't registering anything. I then tried to open the serial monitor in PlatformIO, but that crashed the box. Is there a way to monitor the serial i/o while connected to Eos to see if the messages are being sent or not? What's my next step is sourcing the issue?

  • You can't use the serial monitor and a connection to EOS at the same time.
    The problem comes up after limited number of parameters, this should tested step by step
    by increasing the numbers of parameters and depends also on the name length of the parameters.
    Maybe also the implicit messages overflows the Arduino buffer.
    The best way is to use a Teensy www.pjrc.com/.../ 
    He is is more powerful and there is no real limit of parameters.

  • Cheers for the response. I tried limiting the number of parameters, but even with 4 or 6 parameters the second encoder doesn't work. I think I'm gonna roll with the basic box sketch until I can pick up a teensy.

  • Ok, Arduino Uno is no fun, I personaly use a Leonardo or Micro board beause the build in USB is much better and works with up to 16 parameters, but for extented experience the Teensy is the best solution.

  • Hi, I was wondering if you could help me out again. I picked up a leonardo off aliexpress. It seems to be working fine when I plug it into my macbook, but when I try to use it on my PC Nomad it doesn't recognize it. I appear to be having the same issue described here: https://community.etcconnect.com/etclabs/f/lighthack/24767/using-an-arduino-micro-genuino-with-lighthack-with-nomad-win10

    However I can't seem to even find a boards.txt, nor do I know if the PID/VID of the Micro would work for the leonardo. I've looked in the arduino15 folder and have a preferences.txt, but no hardware folder and no boards.txt. Should I just create one?

  • On macOS the boards.txt is hidden inside the Arduino.app
    But the best way is to use Teensy.

  • Appreciated. I've found boards.txt and edited it with the PID/VID values for the micro, didn't work. I tried copying the values from the Uno, but that also failed. Out of curiosity, how would I go about deciphering what the correct PID/VID to get the PC to recognize my Leonardo? I'll be looking into teensy for all future builds, but I'd like to get this one working since it's already built, and works on my mac.

  • Some boards can't properly spoof an uno.  If they don't use existing "normal" windows usb drivers it won't matter what you tell the computer they are it won't connect properly.  I know you can spoof teensy boards as Uno boards but I don't think a leonardo will work... I would be happy to hear differently if anyone has done this.  When I get some time I will try some additional leonardo tests to see what needs to happen to make it work.

  • Much obliged, I was afraid that might be the situation. Guess I'll be picking up some teensy now.

  • teensy is good.  If you just need loads of pins you can use an mega2560 and it should work with the console.

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

Reply
  • 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.

Children
  • 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.

Related