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).
Related
I've been digging quite a bit into IPMItool commands and have yet to find a comprehensive list of raw hex commands. We have approximately 90 Dell C6220 II machines that I need to set a trigger (Dell calls these Platform Event Filters) to have the system shutdown upon reaching the Upper Critical Threshold that I set (ironically with IPMItool) for inlet temperature. Our Dell rep tells me this isn't possible and that I'll have to pull up the web interface for all 90 machines and set this by hand. They also told me it wasn't possible to set the inlet temperature thresholds with IPMItool and I did that so my faith in Dell is dwindling. What little I've been able to find on the internet it looks like I might be able to make it happen with raw hex commands. Can anyone in the great internet wild help me?
I ended up using the freeipmi tools ipmi-sensors-config and ipmi-pef-config. First I ran ipmi-sensors-config -L | grep Inlet to find which sensor number corresponded to the inlet temp (for my C6220 II machines it was sensor 16, but for my C6320s it was 110, or sometimes 10, so be sure to do this). I then ran ipmi-sensors-config -c -e '16_Inlet_Temp:Upper_Non_Critical_Threshold=30' &&
ipmi-sensors-config -c -e '16_Inlet_Temp:Upper_Critical_Threshold=32'. This sets the temps to what you want, but we're not done. We have to actually have to set an event to react to these. For that I ran ipmi-pef-config -c -e 'Event_Filter_4:Event_Filter_Action_Power_Off=Yes' &&
ipmi-pef-config -c -e 'Event_Filter_5:Event_Filter_Action_Power_Off=Yes'. Event 4 and 5 in my system corresponds to Temp Non-Critical and Temp Critical events for all temp sensors. To find these I ran ipmi-pef-config -o > pefconf.txt, and then used Vim to search for "Temp".
I'm building an application that uses pty.js to open up a pseudo terminal on my computer. I'm getting responses that look like:
]0;ec2-user#ip-172-31-62-237:~[?1034h[ec2-user#ip-172-31-62-237 ~]$ ls
]0;ec2-user#ip-172-31-62-237:~[ec2-user#ip-172-31-62-237 ~]$ pwd
/home/ec2-user
I'm assuming pty.js is sending back a specific encoding, but I'm not sure what the encoding is and how to decode it. Any help would be appreciated, thanks.
Those aren't responses (the terminal would respond), but control sequences sent by an application (not the terminal). I see a few instances (OSC might print as ^[], and CSI as ^[[ if the escape character were shown as ^[):
]0;ec2-user#ip-172-31-62-237:~
looks like the control for setting the window title (from xterm although several programs support it),
OSC Ps ; Pt BEL
OSC Ps ; Pt ST
...
Ps = 0 -> Change Icon Name and Window Title to Pt.
and
[?1034h
looks like another sequence from xterm's repertoire (generally not supported by other programs):
CSI ? Pm h
DEC Private Mode Set (DECSET).
...
Ps = 1 0 3 4 -> Interpret "meta" key, sets eighth bit.
(enables the eightBitInput resource).
For the given example, encoding isn't a factor.
For capturing output from your application, the script program is useful. I use a small utility (unmap) to translate the resulting typescript files into readable form, but cat -v is often adequate for this purpose.
Further reading: XTerm Control Sequences
I intend to set the "don't fragment" flag bit in Go, the same thing as this post while it is in C. I checked the constant list but I didn't find this option. So what is the corresponding option in Go?
Thanks in advance!
How to set "don't fragment" flag bit for TCP packet in Go?
First up you should know that TCP really doesn't like IP fragments. Most if not all major implementations avoid fragmentation for TCP segments by using path MTU discovery.
The TL;DR is that the typical IP packet containing a TCP segment has a DF bit set. You can (and should) try this out. Here I am sniffing a few seconds of traffic between my machine and stackoverflow.com:
% tshark -w /tmp/tcp.pcap tcp and host stackoverflow.com
<wait a few seconds>
% tshark -r /tmp/tcp.pcap -T fields -e ip.flags | sort | uniq -c
186 0x00000002
0x02 means the DF bit is set. I confess in other captures I have seen the occasional TCP segment in an IP packet without a DF bit; I suspect rfc1191 has an explanation for this.
Now back to your question, I think there's no portable way to set the DF bit and this is a more widespread question (there isn't even a POSIX-portable way).
There is (likely) an escape hatch in the relevant package for your implementation under golang.org/x/sys.
For example, on a Unix that supports IP_DONTFRAG such as FreeBSD one could use unix.SetsockoptInt and dig the relevant constant value.
On Linux there is not IP_DONTFRAG, as you discovered from the question you linked. The workaround seems to be to use IP_MTU_DISCOVER which happens to be available as a constant in the unix package. You can use that same unix.SetsockoptInt to set it.
I have to program in assembly the 6502.
I was forced to use the emulator Vice 128
I was told that the Commodore 128 is compatible with the instructions of 6502
I am a novice and I was made a practical demonstration but I did not understand anything.
There was an interface of 80 columns which passed with a command (which one?)
The instructions in machine language or assembly (the program)
were entered directly on this matrix of 80 columns.
Also the data are entered in this matrix.
So is this matrix the memory? Each line represents what?
I was told that this is disassembled code 6502. But I do not know what it means
I'm very confused
I want to run this simple program that
performs the sum of two numbers.
The two numbers are stored in the first page to the word zero and to the word one. I want to store the result in the second word of the first page.
I imagined that the first line contains 80 words. Is that right?
So I put here the data in hexadecimal (3 and 2).
$03 $02
LDA $00
ADC $01
STA $02
But I have a syntax error.
I hope someone can help me because it escapes me how things work.
Thanks in advance
Fir'st, in 6502, we use we deal with bytes, not words. (it's an 8 bit architecture)
You don't mention which macro assembler you are using, but I assume that its trying to interpret $03 as an op code, not data. I looked up two options
in ca65 you can use
.BYTE $03 $02
in dasm you use
HEX 03 02
In addition, 6502 has no concept of 80 anything (words, lines whatever). The only 80 I can think of is the old terminals that had 80 columns. I don't see how this is relevant here.
How to run a disassembled code 6502?
You have to assemble back the code.
Each 6502 instruction stands for 1, 2, or 3 bytes, the first is called the opcode, the optional second or third is the data used by the instruction (the operand).
You need a program to translate the instruction mnemonics to bytes. There were many such programs on the Commodore.
The Commodore 128 had a built-in monitor that let you enter instructions to assemble directly. You can enter it by typing MONITOR at the BASIC prompt. You would need to first set the address, then use "assemble" commands. Then use the "go" command at the starting address to run it. Use BASIC POKE command to set locations containing data, before you enter the monitor. The address 0B00 is a good address to use as it's the tape buffer which is unused except during tape I/O.
Good luck.
As a driver developer WinDbg is one of my best friends.
Now starting with Windows 8, I installed the new WDK and wanted to use its new WinDbg. It has some nice features like remote debugging over the network.
But while using it, I became shocked when I realized that I can only activate 32 breakpoints. The following message is shown:
*******************************************************************************
* You have attempted to enable 33 KD breakpoints, which exceeds the *
* currently supported limit of 32 breakpoints for Windows kernel debugging. *
* Breakpoints exceeding this limit are ignored. *
* Please disable/clear breakpoints until you are within the supported limit. *
*******************************************************************************
This was not the case in earlier versions. Is there a way around this? A option I did not found yet, a registry key or maybe I can patch the executable?
Interesting. The warning messages are coming from dbgeng!AddBreakpoint and in stepping through the code it looks like the limit of 32 is hard coded:
cmp esi, 20h
jbe short loc_100A5721
push offset asc_10038758 ; "***************************************"...
call ?WarnOut##YAXPBGZZ
pop ecx
push esi
push offset aYouHaveAttempt ; "* You have attempted to enable %4u KD b"...
call ?WarnOut##YAXPBGZZ
push 20h
push offset aCurrentlySuppo ; "* currently supported limit of %4u brea"...
call ?WarnOut##YAXPBGZZ
push offset aBreakpointsExc ; "* Breakpoints exceeding this limit are "...
call ?WarnOut##YAXPBGZZ
I suspect that just patching this one check would NOT be sufficient, but I haven't looked any further to confirm that.
You can place int 3 (byte 0xCC) at any address by the following command: eb [address] cc
Make sure to restore the original byte when you hit int 3.