My setup includes a POE camera connected directly to my computer on which I have HDevelop. From the past few days I am running into a problem wherein the first attempt to connect to the camera using HDevelop fails.
When using Connect from the Image Acquisition GUI, I get an error stating "HALCON ERROR. Image acquisition: device cannot be initialized"
When using the open_framegrabber() method from the Program Console, I get a the same error as well, with the addition of the HALCON error code:5312
After I get this error, attempting the connection again, it succeeds. This is the workaround I have at the moment, but its annoying as it keeps repeating quite frequently and I am not sure what is the cause for this issue. I tried pinging my camera from the command prompt which did not show any ping losses. And using the camera from VIMBA viewer I do not get such connection issues.
I know this is not a support site where I should be asking such questions, but if anyone can give me some inputs on solving this, it would be of great help.
Regards,
Sanjay
To solve your question is important to understand the HALCON Framegrabber communication object, I assume that you are coding in HDev code structure.
To create a communication channel with the camera on the proper way, avoiding to reject the connection (due to parameter miss-configuration), you have to specify the camera device ID on the framegrabber creation, and avoid to use default options.
In order to consult, according to your communication protocol, the available devices conected to your board, use:
info_framegrabber('GigEVision2', 'info_boards', Information, ValueList)
where,
The first parameter is the communication protocol and ValueList will throw all the information of the connected devices with a token:param splitted by '|'
i.e
| device:ac4ffc00d5db_SVSVISTEKGmbH_eco274MVGE67 | unique_name:ac4ffc00d5db_SVSVISTEKGmbH_eco274MVGE67 | interface:Esen_ITF_78d004253353c0a80364ffffff00 | producer:Esen | vendor:SVS-VISTEK GmbH | model:eco274MVGE67 | tl_type:GEV | device_ip:192.168.3.101/24 | interface_ip:192.168.3.100/24 | status:busy | device:ac4ffc009cae_SVSVISTEKGmbH_eco274MVGE67 | unique_name:ac4ffc009cae_SVSVISTEKGmbH_eco274MVGE67 | interface:Esen_ITF_78d004253354c0a80264ffffff00 | producer:Esen | vendor:SVS-VISTEK GmbH | model:eco274MVGE67 | tl_type:GEV | device_ip:192.168.2.101/24 | interface_ip:192.168.2.100/24 | status:busy | device:ac4ffc009dc6_SVSVISTEKGmbH_eco274MVGE67 | unique_name:ac4ffc009dc6_SVSVISTEKGmbH_eco274MV
......... and going
In this way you can cast the device ID (device:) automatically, and put this parameter on your framegrabber creation.
open_framegrabber ('GigEVision2', 0, 0, 0, 0, 0, 0, 'default', -1, 'default', -1, 'false', 'here piut the device ID', '', -1, -1, AcqHandle)
At the end you will be able to do a direct connection or create a automatically re-connection routine.
I hope this information helps you.
Related
I am attempting to create an alert that lets me know if a data source stops providing logs to Sentinel. While I know it displays anomalies in log data on the dash board, I am hoping to receive alerts if a source stops providing logs for an extended period of time.
Something like creating a rule with the following query (CEF in this case):
CommonSecurityLog
| where TimeGenerated > ago(24h)
| summarize count() by DeviceVendor, DeviceProduct, DeviceName, DeviceExternalID
| where count_ == 0
I have two similar modems, when I insert the SIM in the first modem it connects automatically to the network. But if I insert the same SIM in the second modem, it doesn't connect to the network.
I launched the command: AT&V to read the profile of each modem. I compared the settings and they are all the same except for the following:
+CGDCONT: (1,"IP","cmnet","0.0.0.0",0,0)
+CGDCONT: (1,"IP","internet","0.0.0.0",0,0)
----------------------
+CIND: 0,3,1,0,0,0,1,0
+CIND: 0,0,0,0,0,0,0,0
----------------------
+CGATT: 1
+CGATT: 0
----------------------
+COPS: 1,0,""
+COPS: 0,2,""
----------------------
Q1: Could one of these settings cause the problem?
Q2: Is there a way to save/restore a modem config?
NB. The first setting of each pair is of the working modem.
Looks like the APN of the second modem is different from the first one. The APN of second modem is "internet", while the first one is "cmnet". This can cause the problem (first one is attached while the second one did not: +CGATT 1 vs 0), if the network does not support "internet" APN.
You can set same APN for the second modem as the first one to have a try. i.e.
AT+CGDCONT =1,"IP","cmnet"
But, APN difference is only one of the possible reasons. For analyzing the actual reason of attach failure, logs are needed.
I have created a RAW socket and set the socket option as "IP_HDRINCL". I am setting the identification field in the outgoing UDP packet and
sending the same out. I see that this field is changed to a random number when the packet is sent out. I can see the same in the sniffer capture.
The same code when built and tested in a different Windows XP machine, works fine ie. I can see that the identification field in the IP header of the outgoing packet carries the same value that I have set.
Not sure whats going wrong. Please let me if you have any insights.
Thanks,
Renu
Raw sockets with IP_HDRINCL automatically set the values of certain field of ip packets that are going to get sent out.
In your case, the packet id will get overwritten in case is zero. (is it your case?)
This are the cases: (taken from Raw Socket man page)
+---------------------------------------------------+
|IP Header fields modified on sending by IP_HDRINCL |
+----------------------+----------------------------+
|IP Checksum |Always filled in. |
+----------------------+----------------------------+
|Source Address |Filled in when zero. |
+----------------------+----------------------------+
|Packet Id |Filled in when zero. |
+----------------------+----------------------------+
|Total Length |Always filled in. |
+----------------------+----------------------------+
I've inherited 3 SBS (now GE Fanuc) C2k single board computers connected over a CompactPCI backplane, and need to get shared memory up and running between them. My understanding is that in previous years, the value for SM_ANCHOR_ADRS was initially "found" by someone, and whenever PMCs were swapped in or out the value for SM_ANCHOR_ADRS was fiddled with until it worked again. This time around, instead of randomly poking memory addresses, I'd like to learn how this value is come about to begin with.
I have noticed in the VxMP manual there's a description of how to compute this address for VME, given a memory map and known offsets. I've tried looking a similar memory map in the C2k user's manual and none exists. (The bits about PCI auto-configuration I saw in the board support package may have something to do with that?)
Also, in case it's useful, relevant bits from the kernel configuration:
Master:
SM_MEM_ADRS NONE
SM_ANCHOR_ADRS (char*)0x4100
SM_ANCHOR_OFFSET 0x4100
SM_INT_TYPE SM_INT_NONE
SM_MAX_WAIT 3000
Slave cards:
SM_MEM_ADRS (SM_ANCHOR_ADRS)
SM_ANCHOR_ADRS (char*)0x84004100 //this is the number that generally gets fiddled with..
SM_ANCHOR_OFFSET 0x4100
SM_INT_TYPE SM_INT_NONE
SM_MAX_WAIT 3000
With this info, how would I go about computing the shared memory anchor address for VxWorks for devices on a CompactPCI backplane?
This is really a function of the PCI bus architecture and its dynamic nature.
The SM_ANCHOR_ADRS represents the shared memory in the PCI address space of the slave card.
The issue is that when you add more cards, the PCI address space can potentially change.
If you use the PCI Auto Configuration you essentially let vxWorks assign the addresses for you. I'm not sure of the assignment order, but I think the address space is allocated in the order devices are detected on the PCI bus.
Let's see if I can illustrate:
PCI Address 3 Devices 4 Devices (Added 1)
0x80000000 (base) +------------------+ +---------------------+
| Host Bridge | | Host Bridge |
| Device (0,0,0) | | Device (0,0,0) |
| 0x01000000 size | | 0x01000000 size |
0x81000000 +------------------+ +---------------------+
| Slave 1 | | Slave 1 |
| Device (0,4,0) | | Device (0,4,0) |
| 0x01000000 size | | 0x01000000 size |
0x82000000 +------------------+ +---------------------+
| Slave 2 | | CPCI Card |
| Device (0,8,0) | | Device (0,6,0) |
| 0x01000000 size | | 0x01000000 size |
0x83000000 +------------------+ +---------------------+
| Slave 2 |
| Device (0,8,0) |
| 0x01000000 size |
+---------------------+
The Device tuple represents (Bus #, Device #, Function #).
The Device # is determined by which slot the PCI card is plugged in. Throw in the possibility of multiple PCI buses and the order in which things get processed can get complicated.
When using the PCI Auto configuration, you specify the base address and size of the PCI memory windows (there are multiple possible PCI memory windows).
The code then goes on the PCI bus and detects the devices. As a device is detected, it tells the PCI system how much memory it needs and the system maps the addresses within the PCI window for that device. In my example, all devices requested 0x01000000 of RAM.
This works well when the PCI configuration is static and doesn't change.
However, as we can see, if we add a new device (the CPCI), then the order of the devices changed, which causes some of the addresses to also change.
PCI Autoconfiguration simplifies the life since you don't have to worry about configuring all the devices ahead of time. They are just discovered.
However, if the configuration is variable, you probably need to configure things manually: i.e. know ahead of time what devices might be present and attempt to configure them. One the upside, you have full control over what address you assign to a given PCI device.
To get back to your question, how do you know the address? If you have access to the vxWorks shell, you can use the pciConfigTopoShow(), which should show you the various PCI devices found and their address spaces.
I've got three XBees. 2x PROs and a standard, all series 2s.
I've configured one PRO and one standard to be router/endpoints on channel 0 and PAN 234 (this is the default channel and PAN ID when selecting the "XBP24-B"/"XB24-B" "ZNET2.5 ROUTER/END DEVICE AT" profile (version 1247 for both).
However the one PRO I've set with the "ZNET 2.5 COORDINATOR AT" profile has a channel of E (though if I keep flashing the device with the same profile, this changes from 12-F).
Obviously if the coordinator doesn't have the same channel, nothing will work, but I can't see any way of setting the channel manually..?
The CH setting in X-CTU is read only, and I can see any other UI element to change the channel:
I've even been into the terminal and typed (words in brackets are what the terminal returns):
+++ (OK)
ATCH (E)
ATCH0 (ERROR)
ATCH 0 (ERROR)
ATCH00 (ERROR)
ATCH 00 (ERROR)
ATCH E (ERROR)
ATCHE (ERROR)
I've Googled and Googled to no avail. incredibly frustrating, can anyone help?!
I've had them working previous as a matter of fluke as I kept flashing the hardware until the channel numbers match up, but this is obviously ridiculous!
Channel selection with the XBee ZB (S2, S2B, S2C) series of modules works differently than with the XBee 802.15.4 (S1) modules. Channel selection is automatic with ZB (as opposed to it being manual with the 802.15.4 modules).
You normally never need to manipulate the channel selection parameters with ZB. Modules find each other and associate with each other if they can.
If your modules just can't seem to find each other it usually comes down to a mismatch in the PAN settings (ID), security settings (LK), or network joining permission settings on the coordinator (NJ).
Not a lot of information exists on the web outside of the Digi's XBee ZB OEM manual. For reference sake, channel selection with ZB works like this:
XBee ZB Coordinator is powered up
The XBee ZB Coordinator reads its SC parameter and builds a list of candidate channels to scan
The XBee ZB Coordinator then performs an energy scan on each candidate channel
The XBee ZB Coordinator then chooses the channel with the least amount of energy on it
This procedure aims to pick a channel with the least amount of noise on it be it from microwave ovens, WiFi networks, or anything else that might be transmitting on the 2.4GHz frequency band.
Any router or end devices joining a network with consult their SC parameters first, then they will try and search for networks they can join which match their PAN and security parameters. They will join and stay joined to the first network they can--with some minor exceptions (see the JV and NW parameters, for example).
If you want to force a channel selection you must set the SC parameter to enable only a single channel. The SC parameter is a bitmask1. Each bit set in the mask will enable one additional channel. What's tricky about this parameter is that the first bit (bit 0) is not channel 0, it's channel 11 (0x0B). For ease of use, if you wanted to lock an XBee ZB to a single channel here would be the values:
+---------------+---------------+------------------+-------------------------+
| Channel (Dec) | Channel (Hex) | XBee ZB SC Value | XBee Availability |
+---------------+---------------+------------------+-------------------------+
| 11 | 0xB | 0x1 | All |
| 12 | 0xC | 0x2 | All |
| 13 | 0xD | 0x4 | All |
| 14 | 0xE | 0x8 | All |
| 15 | 0xF | 0x10 | All |
| 16 | 0x10 | 0x20 | All |
| 17 | 0x11 | 0x40 | All |
| 18 | 0x12 | 0x80 | All |
| 19 | 0x13 | 0x100 | All |
| 20 | 0x14 | 0x200 | All |
| 21 | 0x15 | 0x400 | All |
| 22 | 0x16 | 0x800 | All |
| 23 | 0x17 | 0x1000 | All |
| 24 | 0x18 | 0x2000 | All |
| 25 | 0x19 | 0x4000 | S1, S2B, S2C (not S2) |
| 26 | 0x1A | 0x8000 | S1 only |
+---------------+---------------+------------------+-------------------------+
Obviously if the coordinator doesn't
have the same channel, nothing will
work, but I can't see any way of
setting the channel manually..?
I'm not sure if what you say above is right. From http://ftp1.digi.com/support/documentation/90000976_C.pdf (you should look at the correct version for your hardware, though), it looks like the purpose of a coordinator is to automatically determine the channel:
Coordinator Operation
Forming a Network
The coordinator is responsible for
selecting the channel, PAN ID (16-bit
and 64-bit), security policy, and
stack profile for a network. Since a
coordinator is the only device type
that can start a network, each ZigBee
network must have one coordinator.
After the coordinator has started a
network, it can allow new devices to
join the network. It can also route
data packets and communicate with
other devices on the network. To
ensure the coordinator starts on a
good channel and unused PAN ID, the
coordinator performs a series of scans
to discover any RF activity on
different channels (energy scan) and
to discover any nearby operating PANs
(PAN scan). The process for selecting
the channel and PAN ID are described
in the following sections.
Channel Selection
When starting a
network, the coordinator must select a
"good" channel for the network to
operate on. To do this, it performs an
energy scan on multiple channels
(frequencies) to detect energy levels
on each channel. Channels with
excessive energy levels are removed
from its list of potential channels to
start on.
I've actually never used the Digi XBee radios (just some of their other radios), so I don't know much about coordinators. I think that their user interface typically does expose all of the valid commands, so it probably won't work to try sending them manually (as you discovered).
You may find more experts on the Digi forums.
Hmm. strange, keep going over the settings again and finally got it working with 2-way comms?! :S
Setup one a coordinator
Setup other two as router/end devices
Set the Device High (DH) to 0 and the Device Low (DL) to FFFF (this means everything sent from this module should be received by everyone)
Set Negotiate Channel to 1 (Enabled), which means the only time a router/end device can set it's own channel is when it finds a coordinator on the same channel (this clearly wasn't happening in my case)
Everything else was left as default.
Leave coordinator powered on when configuring router/end devices so you can check they pair correctly.
As I said, I've used this configuration before and it just didn't work, so I don't know what kicked it into life this time, but it worked?!
One thing to take into account is that ZigBee channels extend from 11 to 26, zero is not a valid option.
Since that's the case, are you able to try the command ATCH11 ?
If that command succeeds, then perhaps the ATCH command wants a decimal input between 11 and 26?