I just had to solve this problem myself. I did some back-of-the-envelope calculations and decided a Pi was just too slow to count pulses this fast AND do all the other work I wanted it to do. So I created a small printed-circuit board with the MCP23017 connected to a SN74LV8154 dual counter after searching fruitlessly for a Pi HAT that included a counter. The counter counts the pulses, the MCP23017 interfaces the parallel outputs of the counter to the I2C bus, and I modified the Rexygen-supplied MCP23017 driver to return the count values and multiply them by calibration constants. Another possibility would be to use a separate microcontroller like the STM32 to count the pulses and return the sum by I2C, but I didn't want to learn the entire software environment of the microcontroller just for that one task.

This solution is working very well, however it required electrical engineering knowledge and learning a PC board design tool (kicad).

If you only care about flow rate, another option is to build a RC filter circuit to transform the pulses into a voltage, and use a ADC card to read in the voltage. This doesn't work well for total fluid volume calculations because again, the Pi would be required to integrate the voltages at a high speed.

I'm learning that one of the biggest issues with Modbus is that many of the sensors and effectors have different baud rates, parity settings, and stop bit settings. I have two sensors that have settable baud rates and stop bit counts, but the settings cannot be made to be the same! So I need two buses. Fortunately the interface card I'm using with my Raspberry Pi has two channels on it, which show up as two serial devices. Implementing these in Rexygen is not hard, but there are some things to watch out for.

Creating two modbus instances is as simple as adding two modbus drivers to the exec file by chaining them to the "Drivers" output of the EXEC block.

The Modbus driver in Rexygen uses a configuration file. So, creating two instances of the driver MBM0 and MBM1 will not work if you just add one and then copy it and give it a new name as I first tried to do. Each time I edited a device for MBM1, the one for MBM0 showed up in the driver configuration dialog. Even worse, if I then changed the serial settings, it changed them for the other bus! However by giving each driver instance its own separate configuration file, the problem is solved.

There is no way to move a device setup "item" from one config file to another inside the Rexygen Studio. However, I successfully moved one by copying the text for the item (Everything from "Item {" to the matching "}" from one file to another.

@jaroslav_sobota It does seem to be the way most companies are sharing software these days. It also offers the benefit of being very searchable, so it can attract interest to Rexygen by those wishing to interface to a particular device. For example, I found the actual devices I'm using by searching for drivers on Github for the chips that are inside them. Github with a little management would also allow Rexygen users to provide updates or enhancements to the software contributed by others. The downside is that it isn't as readily accessible for examples as the library you include with the product but there is probably some way to integrate those options...

The MH-Z16 CO2 sensor from Sandbox Electronics is visible at https://sandboxelectronics.com/?product=mh-z16-ndir-co2-sensor-with-i2cuart-5v3-3v-interface-for-arduinoraspeberry-pi It offers rapid response and good accuracy. The part is similar to and based on the one sold by Winsen Electronics, but has been modified by Sandbox to be more easily calibrated, among other enhancements. I am using it to control ventilation in a greenhouse to make sure that there is enough fresh air supplied. It can also be used to enable CO2 supplementation. In the process of testing it, I found that my indoor CO2 was reaching unhealthy levels in my house!

Sandbox offers an Arduino C++ driver which I converted to C-like REXLANG and tested extensively. The unit is very usable inside Rexygen on a Raspberry Pi, and includes a triggerable self-calibration function that coupled with Rexygen's live start from flash allows you to carry the unit outside for unattended calibration.

Source files for download: MH-Z16_example.zip

Continuing on with my greenhouse automation, I need a way to measure light both on top of the canopy of plants (to tell if the lights are working, or if natural light is insufficient for the plants) and under the canopy (to tell how thick the foliage is and when pruning is needed.)

The TSL2561 is a very easy to use simple chip-based sensor. I've included a driver I wrote for it using REXLANG, and a simple application that turns on the lights when it gets dark.

Project source files for download: TSL2561_Example.zip

I'm using PWM signals to control LED lighting brightness in my automated greenhouse. As the number of lights went up, I needed more and more channels of PWM signals. The solution is one of the inexpensive breakout boards with the PCA9685 chip on them, connected to the Raspberry Pi with I2C. Here I've included a REXLANG driver for this chip that can be used to control servo motors, LED light strings, and more.!

This is the PCA9685 card I used: https://www.waveshare.com/servo-driver-hat.htm

Source files for download: PCA9865 Example.zip

Has there been any thought given to CANbus support? Is there any advantage over Modbus that you know of?
I'm operating in a very noisy environment and have to give up on Wifi, which doesn't work well on the Raspberry Pi anyway. So my choices are to use Modbus for device communication and wired LAN for inter-Pi communication, or to try to connect Pis with Modbus which I think will limit the design by restricting the speed and content that can be exchanged. I'm guessing you don't support it for lack of demand?

This is a block I put on every one of my Rexygen machines. It take binary error signals and prioritizes them, then picks a corresponding status value and string description of the highest priority error (stored in parameters) and sends them out to the hmi or email or texting function, etc. It handles 16 error inputs and outputs a bitmask for all active errors to allow further analysis of coincident errors. Finally, it has a masking function where the current errors are masked for a given time period but the system is still sensitive to new errors, essentially "could you please shut that alarm off!"

I'm working on automated greenhouse designs and use text alerts to let me know what's going wrong. This block is essential to tell me what I need to do to react to error conditions.

0_1584658023304_Error_handler.mdl