I can use mbpoll to poll my modbus temperature and depth sensor using
mbpoll -m RTU -t 4 -a 1 -b 19200 -r 45 -c 16 /dev/ttyUSB1
however when I try to display the data as a float in order to make it legible I get an error. I attempt this using the code
mbpoll -m RTU -t 4:FLOAT -a 1 -b 19200 -r 45 -c 16 /dev/ttyUSB1
Right now the data is displayed as a figure such as 16824 but It should read something like 22.4 (being degrees C). Using Modbus Poll on my PC I am able to do this by selecting the cell and choosing to display it is a FLOAT AB CD, so I assumed (probably incorrectly) that this was what I was supposed to do in MBPOLL.
Thanks!
Expanding on the answer in the comments in case someone finds this in the future:
When using modpoll with floating point numbers (e.g. -t 4:FLOAT) two 16 bit registers will be combined to output each 32 bit floating point value. This may mean that modpoll is requesting more registers (32) than expected. The result may be an error if non-existent registers, at the end of the range, are being requested (I'd expect exception 2 - ILLEGAL DATA ADDRESS). This can be resolved by reducing the number of values requested.
I believe you will also need -B (Big Endian) but that would not cause an error (just an unexpected result).
Other than generating an output file then using wc -l output.txt and -1 divide by 2 and head -50 the output.txt, is there any easy way to auto count no of solution inside minizinc and print the first 50 solution?
My program run for 12 hour in one scenario and the other one expected to run 2 days!
Also, any way in batch mode (not ide) to generate resources usage other than using time minizinc ...
Thanks for advice
The command line program "minizinc" as well as most FlatZinc solvers supports the parameter "-n " which is the number of solutions to show. The MiniZinc IDE has the option "Stop after this many solutions:".
Note that this is relevant for satisfaction problems. For optimization problems, however, there is no consensus how different solvers handle "-n".
I would like to turn off the leds of my Raspberry Pi.
I tried modifying the file echo none >/sys/class/leds/led0/trigger but nothing changed.
Is this possible?
RaspberryMediaCenter:/sys/class/leds # echo 0 >/sys/class/leds/led1/brightness
RaspberryMediaCenter:/sys/class/leds # echo 0 >/sys/class/leds/led0/brightness
led0 green one
led1 red one
According to the RaspberryPi forums: echo 1 >/sys/class/leds/led0/brightness #Turn on
echo 0 >/sys/class/leds/led0/brightness #Turn off
Though I think some kernel hacking may be involved to control all of them, I believe this only works with the OK LED.
It's 2022, and the answer today is:
The documentation is located here, but it may or may not be up to date:
on your local file system: /boot/overlays/README
online at GitHub: the README file
The README is a rather choppy document, but you can find enough to get started. The parameters of interest are act_led_*, and pwr_led_*. There are three device tree parameters (dtparam) for both act_led and pwr_led: _trigger, _activelow and _gpio, but the documentation doesn't mention all possible values for them. Through guesswork, I learned the following values will turn the activity/green and power/red LEDs OFF:
To turn both act_led and pwr_led OFF, add these two lines to the file /boot/config.txt, and then reboot:
dtparam=act_led_trigger=none
dtparam=pwr_led_trigger=none
However:
Changes made on Aug 8, 2022 to the Raspberry Pi's proprietary closed-source firmware have rendered the above configuration ineffective on some models of RPi:
Raspberry Pi 3 Model B+
Raspberry Pi 4 Model B
Raspberry Pi 400
Raspberry Pi Compute Module 4
For these models, with firmware versions issued since Aug. 8, 2022, the following configuration is needed to extinguish the Red Power LED (pwr_led):
dtparam=pwr_led_trigger=default-on # The default
dtparam=pwr_led_activelow=off
There are also parameters for extinguishing the Ethernet LEDs also, but they only work for the 3B+ & 4B models: eth_led0 & eth_led1. Fortunately, the documentation does enumerate a set of values for the 3B+ and the 4B.
UPDATE, 3/22/22: Additional details are now posted on GitHub
UPDATE, 8/27/22: A recent software/firmware change by The RPi Organization seems to have broken the device tree configuration (dtparam) that disabled the Red Power LED. A bug report was filed on 2022/08/21. I won't attempt to characterize the maintainer's responses; you may review them & draw your own conclusions.
As of now, I feel that the answer to the OP's question is that "it depends on the Raspberry Pi model". I've edited my answer above based on the latest information, but this saga will likely have more episodes! FWIW, the sysfs interface - deprecated ~ 2 years ago - still seems to be working if the correct file & value are used; the details are presented in another Q&A on the same subject.
UPDATE, 12/27/22:
Any further updates to this answer will be posted to this GitHub repo.
On the Pi you can control the 2 Leds (red and green) by editing the files located under:
/sys/class/leds/led[num]
For example to turn off the usual blinking of the green led when the Pi is accessing the sd card, you can run (as admin):
echo none > /sys/class/leds/led0/trigger
And to turn on or off one led, you can change the status of the brightness file (as admin):
echo 1 > /sys/class/leds/led0/brightness # turn on
echo 0 > /sys/class/leds/led0/brightness # turn off
This is my very inelegant workaround in Python to actually control the status:
import time
import os
# turn off the default trigger of the green LED
os.system("sudo bash -c \"echo none > /sys/class/leds/led0/trigger\"")
# turn on the green LED
os.system("sudo bash -c \"echo 1 > /sys/class/leds/led0/brightness\"")
# keep it on 5 seconds
time.sleep(5)
# turn off the green LED on PI
os.system("sudo bash -c \"echo 0 > /sys/class/leds/led0/brightness\"")
Depending on which LED you are talking about, it looks like it is not possible.
For more information, read How can I turn the lights off on my pi? (and that's also a good place to ask RPi questions)
I realize that this is an old question. But, it was the first in the Google results for me, and it didn't work for my Raspberry Pi2 B+. For anyone else like me finding this now, the techniques at http://www.jeffgeerling.com/blogs/jeff-geerling/controlling-pwr-act-leds-raspberry-pi did work.
At the moment I am using something like this to run a c++ program:
mpirun -np 4 ./test
This works fine, but the problem is that I am wrapping the c++ program with Python. So I want to set the number of processors in Python and deliver it to the c++ program.
Is it possible to set the number of used processors e.g. as fixed value in the c++ code without using the command line? How does a simple example look like?
by -np N , you set number of process, not the number of processors.Processors are further assigned to each process depending upon the flags you are providing during execution or the rank file , if you are using. And if you are focusing on the Python & C++ interaction , i think there should be a way to call cmd functions something like exec().You can easily call whatever you want to be executed on the system command line !
I'm trying to find a way to start a perl process up under the debugger, but have in just start running automatically without stopping at the first statement and having me enter 'c' to start it. This module is run by a larger system and I need to be able to periodically (based on external conditions) interrupt the program via interrupt signal, examine some data structures and have it continue.
Obviously, I can have the supervising program start my process using "perl -d myProcess", but how to get it to just run without the initial break. Anybody know how to get this to happen?
Much Thanks.
Thanks. That was a big hint. I see several options including "NonStop".
It looks like using the line PERLDB_OPTS="NonStop" perl -d myprog.pl & does the trick. Then I just kill -INT <pid> and fg it to get it up in the debugger. After I 'c' to continue executing and bg it so it will continue.
You can also add this config option to the .perldb file. The format of the config file is a bit unusual and not so well documented, so here goes
DB::parse_options("NonStop=1");
Other useful options:
DB::parse_options("dumpDepth=3");
DB::parse_options("PrintRet=0");
$DB::deep = 1000;