Welcome to EnviroDIY, a community for do-it-yourself environmental science and monitoring. EnviroDIY is part of WikiWatershed, a web toolkit designed to help citizens, conservation practitioners, municipal decision-makers, researchers, educators, and students advance knowledge and stewardship of fresh water. New to EnviroDIY? Start here

Adding a new modbus sensor using current ones as inspiration.

Home Forums Environmental Sensors Adding a new modbus sensor using current ones as inspiration.

Viewing 5 reply threads
  • Author
    Posts
    • #17053
      Erik G
      Participant

      I would like to add a gas sensor which communicates over RS485 to work with the modular sensor library but having the normal issues with me lacking the programming skills needed.

      I have used the Yosemitech and Keller librarys as a template and tried to make it as basic as possible.

      When checking the example code for the modbus sensors i get confused about the order of the two different power pins in the constructor. Is it not referenced by the order in the number of parameters?

      From the “Example code” used in the menu a la carte example:

      In the file KellerNanolevel.h:

      It is flipped in all the modbus sensors or am I missing some basic C++ knowledge. How does it work?

       

    • #17054
      neilh20
      Participant

      Hello Erik, sounds like you are on the path to learning Cpp.  One issue to keep in mind is that the code is what happens, the reality check, the documentation is for readability.  You may want to  list what gas sensor you are looking at for the max help.

      So I don’t follow your question  – where do you get the code snippet from the first section  which says there are two power pins “nlAdapterPower” and nanolevelPower   which looks reasonable.

      Then in the constructor KellerNanolevel.h they map to int8_t and int8_t – the name is only descriptive, it isn’t used for anything.

      Part of new code is having a plan including figuring out what you need to learn. a) can you get enough technical detail for the plan to be likely to work – ie for your case the Modbus map of the gas sensor  b) The other part of coding is set up a target test bench. b1) The first part of a test bench is proving that the test bench is working, b2) typically by enabling debug and checking the message flow on a known working sensor and then b3) making modifications for your new target sensor.  Do you have ANY ModularSensors modbus sensors that you could start with?   Just a thought 🙂

    • #17055
      Erik G
      Participant

      Hi Neil,

      It is very basic but I guess every journey must start somewhere…

      The first code snippet is from the example code in the menu a la carte example. I’ve edited my first post just to clarify that.

      The second one is from the Modular sensor library.

       

    • #17058
      neilh20
      Participant

      Hello Erik, I’m sorry I still don’t understand your question.

    • #17061
      Erik G
      Participant

      Sorry for being so vague. I will try to clarify.

      Is it not the order of the parameters given in the constructor that matters when creating a new object?

      If the sensor constructor looks like this:

      And the initialization like this:

      Would not the power pins be the opposite of intended?

       

    • #17064
      neilh20
      Participant

      Hello Erik, hmm perhaps I’m coming from too many years of reading code,

      Yes the order matters for the code, that the instance follows the the constructor.

      What you are looking at I think is  “// .. sensor” , and that  is a comment

      It does look like it may have been swopped, but its only descriptive text.  Getting descriptions to match the code takes time and refinement.  The “code warrior” answer;  is read the code 🙂 .

      FYI IMHO  adding a new protocol for a Modbus  device is jumping into some “deep water”. Good luck!

Viewing 5 reply threads
  • You must be logged in to reply to this topic.