2022-05-30 at 12:27 PM #17053
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:1234567const int8_t nlAdapterPower = sensorPowerPin; // RS485 adapter power pinconst int8_t nanolevelPower = A3; // Sensor power pin// Create a Keller Nanolevel sensor objectKellerNanolevel nanolevel(nanolevelModbusAddress, modbusSerial, nlAdapterPower,nanolevelPower, nl485EnablePin,nanolevelNumberReadings);
In the file KellerNanolevel.h:123456789101112* @param powerPin The pin on the mcu controlling power to the Nanolevel.* Use -1 if it is continuously powered.* - The Nanolevel requires a 9-28 VDC power supply.* @param powerPin2 The pin on the mcu controlling power to the RS485* adapter, if it is different from that used to power the sensor. Use -1 or* omit if not applicable.KellerNanolevel(byte modbusAddress, Stream* stream, int8_t powerPin,int8_t powerPin2 = -1, int8_t enablePin = -1,uint8_t measurementsToAverage = 1)
It is flipped in all the modbus sensors or am I missing some basic C++ knowledge. How does it work?
2022-05-30 at 2:11 PM #17054
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 🙂
2022-05-31 at 4:34 AM #17055
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.
2022-05-31 at 12:07 PM #17058
Hello Erik, I’m sorry I still don’t understand your question.
2022-06-01 at 3:32 AM #17061
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:123456KellerNanolevel(byte modbusAddress,Stream* stream,int8_t powerPin, //Power pin of sensor.int8_t powerPin2 = -1, //Power pin of RS485 module.int8_t enablePin = -1,uint8_t measurementsToAverage = 1)
And the initialization like this:1234567// Create a Keller Nanolevel sensor objectKellerNanolevel nanolevel(nanolevelModbusAddress,modbusSerial,nlAdapterPower, //Power pin of the RS485 adapternanolevelPower, //Power pin of the sensornl485EnablePin,nanolevelNumberReadings);
Would not the power pins be the opposite of intended?
2022-06-01 at 12:24 PM #17064
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!
- You must be logged in to reply to this topic.