I'm trying to get two computers to communicate with each other over firewire. Both of the computers are running Ubuntu 9.10 and both have read/write access to the /dev/raw1394 node. I'm using firecontrol to quickly test sending read/write requests. If I can get it to work with firecontrol, I should be able to figure out how to do the same in my code.
On computer A, I do this:
computerA $ ./commander
Work Now
Copyright (C) 2002-2007 by Manfred Weihs
This software comes with absolutely no warranty.
No adapter specified!
successfully got handle
current generation number (driver): 1
1 card(s) found
nodes on bus: 2, card name: ohci1394
using adapter 0
found: 2 nodes on bus, local ID is 1, IRM is 1
current generation number (adapter): 7
entering command mode
Type 'help' for more information!
Command: w . 0 0 0xDE
insufficient arguments for operation!
Command: w . 0 0 2 0xDe
writing to node 0, bus 1023, offset 000000000000 2 bytes:
00 DE
write succeeded.
Ack code: complete
Since computer A is on node 1, I send to node 0. Then I go to computer B and read from node 0 and get this:
computerB $ ./commander
Copyright (C) 2002-2007 by Manfred Weihs
This software comes with absolutely no warranty.
No adapter specified!
successfully got handle
current generation number (driver): 1
1 card(s) found
nodes on bus: 2, card name: ohci1394
using adapter 0
found: 2 nodes on bus, local ID is 0, IRM is 1
current generation number (adapter): 9
entering command mode
Type 'help' for more information!
Command: r . 0 0 1
reading from node 0, bus 1023, offset 000000000000 1 bytes
read failed.
Ack code: pending; Response code: address error
I'm using the same offset for both of them. What am I doing wrong and how am I supposed to read/write from/to firewire nodes?
I have these same problems when I try and use raw1394 in my own code.
Related
I am trying to use Xyce for a project and am running into this issue. I am copying the DC sweep netlist example from the Xyce user guide on page 39 to notepad and saving it as test2c.cir. I then copy it over into the Xyce directory and run the Xyce terminal and run the simulate command and am unable to generate any output. Is there a step I am missing to be able to run the Diode Clipper Circuit DC Sweep file? Am I saving the cir file in the right directory? It seems that the circuit "loads properly" and the syntax is fine, but I am not getting a figure output I am expecting. I believe the issue might be that my PC doesnt have a way to open prn files, in that case, how would I fix that?
Diode Clipper Circuit
** Voltage Sources
VCC 1 0 5V
VIN 3 0 0V
* Analysis Command
.DC VIN -10 15 1
* Output
.PRINT DC V(3) V(2) V(4)
* Diodes
D1 2 1 D1N3940
D2 0 2 D1N3940
* Resistors
R1 2 3 1K
R2 1 2 3.3K
R3 2 0 3.3K
R4 4 0 5.6K
* Capacitor
C1 2 4 0.47u
.MODEL D1N3940 D(
+ IS=4E-10 RS=.105 N=1.48 TT=8E-7
+ CJO=1.95E-11 VJ=.4 M=.38 EG=1.36
+ XTI=-8 KF=0 AF=1 FC=.9
+ BV=600 IBV=1E-4)
.END
And this is the directory...
UPDATE:
I changed the Analysis Command to save files as different formats (csv, raw, dat) and it still gives me the same error. Aborts because it cant open test.cir.___. Is the problem maybe something to do with where the program directory is located?
I was informed what a possible fix would be and it worked. The Xyce installation was in a location without admin permission (by default after serial installation). The easiest thing to try that worked was to cd to another directory with the netlist file and run Xyce in that other directory. That generated the output file correctly!
I'm able to read DS18B20 sensors using the example code provided in this repository.
It works well using a standard Espressif ESP32-WROOM-32 (aka ESP32-DevKitC), which uses a 40 MHz XTAL.
I'm not able to run the same example using an Allnet-IOT-WLAN, which uses a 26 MHz XTAL.
I suspect that the problem is related with RMT initialization. The initialization is using:
rmt_tx.clk_div = 80;
I've tried different settings for clk_div with no luck.
Does anyone know how to use the DS18B20 sensor with ESP-IDF, using a board with a 26 MHz XTAL, instead of more standard 40 MHz one?
ESP32-WROOM-32 output (working)
I (0) cpu_start: Starting scheduler on APP CPU.
Find devices:
0 : d4000008e40d7428
1 : f8000008e3632528
Found 2 devices
Device 1502162ca5b2ee28 is not present
Temperature readings (degrees C): sample 1
0: 22.3 0 errors
1: 21.8 0 errors
Temperature readings (degrees C): sample 2
0: 22.3 0 errors
1: 21.9 0 errors
Allnet-IOT-WLAN output (not working)
I (0) cpu_start: Starting scheduler on APP CPU.
Find devices:
Found 0 devices
E (6780) owb_rmt: rx_items == 0
E (6880) owb_rmt: rx_items == 0
E (6980) owb_rmt: rx_items == 0
There are no differences in the RMT initialization using different XTAL clock frequencies.
D (2319) rmt: Rmt Tx Channel 1|Gpio 25|Sclk_Hz 80000000|Div 80|Carrier_Hz 0|Duty 35
D (2319) intr_alloc: Connected src 47 to int 13 (cpu 0)
D (2319) rmt: Rmt Rx Channel 0|Gpio 25|Sclk_Hz 80000000|Div 80|Thresold 77|Filter 30
Both use the same 80 MHx source.
I was using a wrong pinout diagram. I've tested the RMT with a more simple example and I found out that the pinout was wrong.
The DS18b20 sensors works well with a 26 MHz XTAL with the esp32-ds18b20 library.
I am able to communicate with a ventilation installation (Helios KWL EC 500 W which supports holding registers only, english description starts at 50% of the file) using the modpoll utility v3.4. But I failed to transfer the very first communication to Ruby and the rmodbus library v1.3.3.
With modpoll, I may request some temperature value with the command
./modpoll -m tcp -a 180 <ipaddr> 0x7630 0x3031 0x3034 0x0000
and then read the data using
./modpoll -m tcp -a 180 -t4:hex -c 8 -0 -1 <ipaddr>
Protocol configuration: MODBUS/TCP
Slave configuration...: address = 180, start reference = 1 (PDU), count = 8
Communication.........: x.x.x.x, port 502, t/o 2.00 s, poll rate 1000 ms
Data type.............: 16-bit register (hex), output (holding) register table
-- Polling slave...
[1]: 0x7630
which outputs 8 16bit registers as stated as example in the Helios modbus documentation. As very first step, I tried to move the read part to Ruby. However, my Ruby code times out:
require 'rmodbus'
ModBus::TCPClient.new(ipaddr, 502) do |client|
client.with_slave(1) do |slave|
slave.debug = true
puts slave.holding_registers[180..187]
end
end
and throws the exception
/var/lib/gems/2.3.0/gems/rmodbus-1.3.3/lib/rmodbus/slave.rb:241:in `rescue in query':
Timed out during read attempt (ModBus::Errors::ModBusTimeout)
from /var/lib/gems/2.3.0/gems/rmodbus-1.3.3/lib/rmodbus/slave.rb:232:in `query'
from /var/lib/gems/2.3.0/gems/rmodbus-1.3.3/lib/rmodbus/slave.rb:164:in `read_holding_registers'
What's wrong?
I am not sure if / how to use the parameters output by modpoll "address =180" and "start reference =1". Is "address" equivalent to "holding register #"?
Okay, this one was rather stupid. For the records (and others who might want to talk to their Helios using rmodbus):
slave.debug = 1
turns on the debugging which outputs the byte stream sent to the modbus slave. The first bytes sequence is supposed to be: transaction number (2 byte), protocol specifier (2 byte, always zero), size of the following message (2 byte), unit identifier (1 byte, always 180 for Helios KWL).
The slave needs to be initialized with its unit identifier 180, instead of 1:
client.with_slave(180) do |slave|
When searching for an occurrence of text in a PostScript file, I receive the following error:
gsapi_run_string_continue returns -21
The API documentation specifies that return codes > 0 are "Error" but doesn't describe it any more specifically. Full error console output below - error occurs twice identically, only one occurrence displayed here.
GPL Ghostscript 9.15 (2014-09-22)
Copyright (C) 2014 Artifex Software, Inc. All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
Displaying DSC file C:/Users/c-toothm/Desktop/PRDFlow12_30_2014_050307/1230ouptut.ps
Displaying page 1
%%[ ProductName: GPL Ghostscript ]%%
%%[ LastPage ]%%
Extracting text using pstotext...
Ghostscript returns error code -21`
--- Begin offending input ---
evice /pop , d
initmatrix [1 0 0 1 0 0] concat colspSet`
0.00 43.32 +
0.94 0.95 +S
(XSFT2200041.img) run
EPSFILE2200041 restore
;
0 0 0 sco 5 Lw N 4950 4742 M 4800 4742 I K
0 0 0 sco 5 Lw N 4950 4752 M 4800 4752 I K
0 0 0 sco 5 Lw N 4950 4762 M 4800 476
--- End offending input ---
gsapi_run_string_continue returns -21`
[duplicate error redacted]
Our production output creates a giant .ps file every day and this error occurs in many, but not all, .ps files when searching for text. Randomly selected .ps files from the web do not throw the error, so this GS build seems OK - definitely a problem with my file.
What "offending input" is being referred to here and what can I do to address it?
I'd need to see the PostScript file to tell you exactly what is wrong, but 'evice' is not a PostScript operator and so that is likely the problem. Also, from ghostpdl/gs/psi/ierrors.h error code -21 is e_undefined which means the interpreter has encountered an undefined token, which is some confirmation that this is the problem.
This could be because the file contains a 'typo' like that (perhaps it should be setpagedevice or something), or it could be because a filter is improperly terminated, or has insufficient data, and consumes extra bytes from the input stream, chewing up your program.
You should start by using the Ghostscript executable and reproduce the error with that (you might also try the display device, to see whether the problem is related to pstotext), that will allow you to give a command line which other people can then duplicate. With that, and a copy of the offending file I can tell you exactly what's wrong, without it, not much hope.
Bear in mind that PostScript is an interpreted programming language, so its pretty much impossible to tell you what's wrong with your program without seeing the code.
FWIW you might like to try the Ghostscript txtwrite device instead of pstotext, the device doesn't rely on tinkering with the language like pstotext does. pstotext is also really old (the last release is coming up on its 11th birthday) and unsupported.....
I installed Linpack on a 2-Node cluster with Xeon processors. Sometimes if I start Linpack with this command:
mpiexec -np 28 -print-rank-map -f /root/machines.HOSTS ./xhpl_intel64
linpack starts and prints the output, sometimes I only see the mpi mappings printed and then nothing following. To me this seems like random behaviour because I don't change anything between the calls and as already mentioned, Linpack sometimes starts, sometimes not.
In top I can see that xhpl_intel64processes have been created and they are heavily using the CPU but when watching the traffic between the nodes, iftop is telling me that it nothing is sent.
I am using MPICH2 as MPI implementation. This is my HPL.dat:
# cat HPL.dat
HPLinpack benchmark input file
Innovative Computing Laboratory, University of Tennessee
HPL.out output file name (if any)
6 device out (6=stdout,7=stderr,file)
1 # of problems sizes (N)
10000 Ns
1 # of NBs
250 NBs
0 PMAP process mapping (0=Row-,1=Column-major)
1 # of process grids (P x Q)
2 Ps
14 Qs
16.0 threshold
1 # of panel fact
2 PFACTs (0=left, 1=Crout, 2=Right)
1 # of recursive stopping criterium
4 NBMINs (>= 1)
1 # of panels in recursion
2 NDIVs
1 # of recursive panel fact.
1 RFACTs (0=left, 1=Crout, 2=Right)
1 # of broadcast
1 BCASTs (0=1rg,1=1rM,2=2rg,3=2rM,4=Lng,5=LnM)
1 # of lookahead depth
1 DEPTHs (>=0)
2 SWAP (0=bin-exch,1=long,2=mix)
64 swapping threshold
0 L1 in (0=transposed,1=no-transposed) form
0 U in (0=transposed,1=no-transposed) form
1 Equilibration (0=no,1=yes)
8 memory alignment in double (> 0)
edit2:
I now just let the program run for a while and after 30min it tells me:
# mpiexec -np 32 -print-rank-map -f /root/machines.HOSTS ./xhpl_intel64
(node-0:0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15)
(node-1:16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31)
Assertion failed in file ../../socksm.c at line 2577: (it_plfd->revents & 0x008) == 0
internal ABORT - process 0
APPLICATION TERMINATED WITH THE EXIT STRING: Hangup (signal 1)
Is this a mpi problem?
Do you know what type of problem this could be?
I figured out what the problem was: MPICH2 uses different random ports each time it starts and if these are blocked your application wont start up correctly.
The solution for MPICH2 is to set the environment variable MPICH_PORT_RANGE to START:END, like this:
export MPICH_PORT_RANGE=50000:51000
Best,
heinrich