Good morning,
I'm working with your products and I'm a very satisfied customer, but today I'm starting a new (big) project and I'm using the DIO and counters.
I'm asking for some firmware updates, because I think that counters are not well and completly implemented.
- we need to be able to start and stop a counter, possibily with a write command of the variable;
- the counter value must be saved in eeprom, we can't lose it if the device reboots for a current loss or any other reason;
- It would be better to reset a counter just knowing the name of a variable and not the slave address (like read/write);
- Some other functions like max value before reset etc... not fundamental but usefull.
Without this features, I have to to use another hardware like a modbus plc...
Thank you very much
DIO firmware update request
Re: DIO firmware update request
Hi,
thanks for your very valuable ideas and suggestions. We know that the counter / encoder function is not a highly sophisticated implementation in our DIO. It was not planned to have it in there but added when we had already published the details of our modules in our blog. You may read about this here:
https://revolution.kunbus.com/io-module-update/
But you may also find that we not yet have implemented some ideas which we mention in this blog article . This is because of a prioritisation schedule in the project. It seems most of the users who are using the counter function are content with the implemented features and those who do need additional features also very often do need a faster counter or a faster possibility of reactions to the counter value. As we are limited to the basic electronics of our module (i.e. to the chain of RS485 PiBridge - STM CPU - SPI Bus - Input circuit) we can't get any faster. So the counter / encoder will be limited to applications like meter counts etc. With such applications users can live with the speed and other limitations.
We will definitely not ignore your proposals but I also do not see any chance to implement them ad hoc within short range of time. May be you could use work around like I have used when using the counter inputs in connection with flow meters:
I implemented a virtual software counter in my application and saved the actual count of the 4 byte DIO counter as a start value whenever I would normally reset the counter. The virtual counter then used a simple subtraction of the actual counter value and the stored start value. When using simple binary arithmetic you do not need to care about wrap around as e.g. 0xf - 0xFFFFFFE results in 0x11. This solution also covers the ability to start and stop counting.
Storing the counter value to be saved in case of a power failure is a tricky topic: You need to keep in mind that we are dealing with eMMC / flash technology which has limited write/erase cycles. If you use fast counting and want to save each value e.g. per 1 ms you would end up with 4 x 3.600.000 values per hour that is about 14 MB/h and would need just 12 days to fully use every single cell of the eMMC. Having several hundreds of cycles you would possibly get to an end after some years. But when you use more than just one counter you might really overstress your flash device and will run into severe troubles. On the other hand when you need to save the value e.g. every second I can't see any impediment to do this by application software. With my application e.g. I was pushing the actual counter value to a cloud every second. At the end of the day it is all about arithmetic: If your count value changes in an interval which is fastest about 1 second you could poll the counter value in our process image every 500 ms, subtract the start value and save the result in a file . The system load for such actions is near to nothing. If the fastest interval is more in the range of a ms than this will be a major problem: PiBridge will only give you a resolution of 4 to 10 ms depending on how many data is transferred every cycle. So in the process image you will miss certain counts when they happen and could not react or store them.
But may be if you try and explain your application we could think of a work around and try to analyse if there would be a possibility of a software solution with the limits set by our hardware.
thanks for your very valuable ideas and suggestions. We know that the counter / encoder function is not a highly sophisticated implementation in our DIO. It was not planned to have it in there but added when we had already published the details of our modules in our blog. You may read about this here:
https://revolution.kunbus.com/io-module-update/
But you may also find that we not yet have implemented some ideas which we mention in this blog article . This is because of a prioritisation schedule in the project. It seems most of the users who are using the counter function are content with the implemented features and those who do need additional features also very often do need a faster counter or a faster possibility of reactions to the counter value. As we are limited to the basic electronics of our module (i.e. to the chain of RS485 PiBridge - STM CPU - SPI Bus - Input circuit) we can't get any faster. So the counter / encoder will be limited to applications like meter counts etc. With such applications users can live with the speed and other limitations.
We will definitely not ignore your proposals but I also do not see any chance to implement them ad hoc within short range of time. May be you could use work around like I have used when using the counter inputs in connection with flow meters:
I implemented a virtual software counter in my application and saved the actual count of the 4 byte DIO counter as a start value whenever I would normally reset the counter. The virtual counter then used a simple subtraction of the actual counter value and the stored start value. When using simple binary arithmetic you do not need to care about wrap around as e.g. 0xf - 0xFFFFFFE results in 0x11. This solution also covers the ability to start and stop counting.
Storing the counter value to be saved in case of a power failure is a tricky topic: You need to keep in mind that we are dealing with eMMC / flash technology which has limited write/erase cycles. If you use fast counting and want to save each value e.g. per 1 ms you would end up with 4 x 3.600.000 values per hour that is about 14 MB/h and would need just 12 days to fully use every single cell of the eMMC. Having several hundreds of cycles you would possibly get to an end after some years. But when you use more than just one counter you might really overstress your flash device and will run into severe troubles. On the other hand when you need to save the value e.g. every second I can't see any impediment to do this by application software. With my application e.g. I was pushing the actual counter value to a cloud every second. At the end of the day it is all about arithmetic: If your count value changes in an interval which is fastest about 1 second you could poll the counter value in our process image every 500 ms, subtract the start value and save the result in a file . The system load for such actions is near to nothing. If the fastest interval is more in the range of a ms than this will be a major problem: PiBridge will only give you a resolution of 4 to 10 ms depending on how many data is transferred every cycle. So in the process image you will miss certain counts when they happen and could not react or store them.
But may be if you try and explain your application we could think of a work around and try to analyse if there would be a possibility of a software solution with the limits set by our hardware.
Unser RevPi Motto: Don't just claim it - make it!
