I am running a Windows 7 guest system with an Ubuntu 14 host, using VirtualBox, and have run into a problem running even the simplest examples provided by National Instruments, using the ANSI C API for NI-DAQmx.
The first time the DAQ Device is powered on, I can run a single measurement, and after that, any other measurement displays the following error message:
Attempted to read samples that are no longer available.
The requested sample was previously available, but has since been overwritten.
Increasing the buffer size, reading the data more frequently, or specifying
a fixed number of samples to read instead of reading all available samples
might correct the problem.
Property: DAQmx_Read_RelativeTo
Corresponding Value: DAQmx_Val_CurrReadPos
Property: DAQmx_Read_Offset
Corresponding Value: 0
Task Name: _unamedTask(0)
Status Code: -200279
In order to be able to start a new measurement, I have to restart the DAQ device, probably in order to clear any internal buffers that are being overridden.
I am interested in running a basic continuous voltage measurement using a callback function. (The ContAcq_IntClk example provided by NI)
The exact same configuration, same version of NI-DAQmx(9.7.5), and running on Visual Studio 2012, runs smoothly on a machine running Windows 7 directly.
I suspect the problem is with the internal buffer being somehow messed up because of the connection with the Virtual Machine, but can't figure out an elegant solution to fix it.
The device I am using is NI USB-6289.
FIXED:
VirtualBox seems to have compatibility issues with NI USB devices. It appears to work, but it's unpredictable.
VMWare works much better. Switched to VMWare Player and now works flawless.
Related
I was following the nvprosamples creating the direct display to prevent the OS to affect the usage of it as described in this nvidia sample:
[ddisplay sample][1] [1]: https://github.com/nvpro-samples/gl_render_vk_ddisplay
This was approx one year ago, using Vulkan 1.1, everything was working fine.
After upgrade to 1.3 creation of the swapchain was not possible as it seemed that display was not made available for vulkan api anymore, _device->createSwapchainKHRUnique resulting to eErrorInitializationFailed.
This init error was possible to fix by adding the vkAcquireWinrtDisplayNV call which seems that in new version is somehow making the display available for swapchain (surface), same stuff was added to the new version of the nvidia sample.
The problem is that it seems that after the application finishes the monitor is still hanging in some vacuum, invisible for the OS anymore, the process of the application becomes hanging in the taskmanager, without posibility to kill it anyhow (niether admin forced task kill will work as it will state that no instance of the process is running). Even the computer is not possible to be restarted (as the restart screen hangs indefinitely). The Nvidia's sample is causing the same behaviour as mine app.
Is there any way to return the display back to the OS when application ends withou powering off and on the workstation?
I tried to use vkReleaseDisplayEXT on destruction, but without any success (it is also not used anywhere in the sample code if I am not blind).
I develop a few tools in C# using the .Net framework and I am considering the move to Mono. Based on the compatibility analyzer tool (MOMA), the only compatibility issue is the licensing code:
I use Window's serial number and a few other things to generate a computer ID which I then use to generate and manage my licenses.
Obviously, Windows will not be available on Linux or Mac, so I need another way to generate a computer ID.
What can I use in mono to create a reasonably reliable computer ID?
Use a MAC Address:
Get MAC Address in linux using mono
That should be unique to a given network interface, which would uniquely identify the machine.
Also, see this thread discussing the pitfalls and issues related to DRM in mono.
You can use a combination of either CPUID and a hard drive serial number.
As for your code, there is not going to be an elegant way to do this with a one-liner. You will have to check which platform you are running on via Environment.OSVersion. And then based on that, branch your code to do system-specific access. For example, to get CPUID/hdd serial number, use a WMI query; or parse the output of hdparm -I /dev/hda and go from there.
You could use a portion of how Microsoft checked hardware for Windows XP activation. They checked 10 items
Display Adapter
SCSI Adapter
IDE Adapter (effectively the motherboard)
Network Adapter (NIC) and its MAC Address
RAM Amount Range (i.e., 0-64mb, 64-128mb, etc.)
Processor Type
Processor Serial Number
Hard Drive Device
Hard Drive Volume Serial Number (VSN)
CD-ROM / CD-RW / DVD-ROM
When XP was (re)installed/activated it'd contact their servers and if 7 or more of the above items were unchanged it would activate without the need to speak with anyone.
I, personally, would recommend against using the MAC address. As you mentioned, it can be easily changed. Additionally, most machines have two or more network cards now (wired and wireless). It gets worse with virtualization as the MAC can be changed even more easily than the physical one can (do you license differently for virtual environments?)
Another option, instead of checking all 10 hardware components, is to use the UUID of the root file system. The downside of this, is that if the drive ever has issues, the license needs to be reacquired.
sudo blkid
/dev/sda1: TYPE="ntfs" UUID="72C0DE8EC0DE57C5" LABEL="windows"
/dev/sda2: UUID="30fcb748-ad1e-4228-af2f-951e8e7b56df" SEC_TYPE="ext2" TYPE="ext3"
/dev/sda5: TYPE="swap" UUID="8c4e69f8-5074-42c0-8134-0b2429c4c02c"
/dev/sdb1: SEC_TYPE="msdos" UUID="4848-E35A" TYPE="vfat"
I'm now trying to write a program which can perform VM migration from one host machine to another within the same data center based on their current CPU temperature automatically. (Basically from hotter machine to cooler one).
I'm now playing around with Xenserver, on which I can perform VM migration easily (Using XenCenter on the controller machine).
I have already come up with the algorithm to select source and destination machine according to their temperature and resource utilization.
However when it comes to writing a real program, I have no idea where to begin with. I would really appreciate your help if anyone can give me some guidance and help.
The program basically consist of two part: One for center control, installed on the management host. And one for guest host(local control). Which should run on dom0 of guest host.
Local control part are suppose to gather CPU temperature and resource utilization information of the local host and all VMs that runs on it. Gathered info will be send to center control part upon request.
Center control part will check the status of all guest host every 5 minutes (By sending request to obtain latest local info). If any of the guest machine gets over-heat, the control machine will choose a destination host and migrate some VMs from the over-heated host to the destination host.
Can I make use of the existing functionality of Xenserver/Xencenter software and how?
What programming language is best for this task ? I know C, C++, Java but can learn the others fast.
Thanks so much for your time!
I have used Python but the Java API is also good.
First have a look at the XenServer Management API that they are exposing for programmers.
Next download the library XenAPI.py to connect with xenserver.
Now to migrate a VM you need the following parameters vm_reference & destination_host_reference .
vm_reference = XenAPI.VM.get_by_uuid(vm_uuid)
destination_host_reference = XenAPI.host.get_by_uuid(destination_host_uuid)
Now migrate the VM :
XenAPI.VM.pool_migrate(vm_reference , destination_host_reference , {"live": "true"})
I have built my own USB HID device. I want to check, if it is working correctly.
I want to check the descriptors sent by the device, display input reports and send output reports. What tools are capable of this task and runs on Windows 7 64 bit?
On a day-to-day basis I use USBlyzer. It works well on Windows 7 64-bit.
As far as free tools go, the Windows DDK includes (in C:\winddk\7600.16385.1\tools\avstream\amd64) a tool called UVCview.exe ("USB device viewer") that shows at least some descriptor information.
You might also try Wireshark, but I admit, I only use it for network and can't speak to the quality of its USB capture.
(even though it's an old post) - here is a convenient and free solution:
Our Docklight Scripting software can test custom USB HID devices in the free (evaluation) download already, no time limit. Tested both on Windows 7 and Windows 10. You can access your device via the chosen VID and PID, display input report data and send output reports, even with variable output report ids.
I need to dual boot 2 different task sequences (Win7 images) for different Pc types which require different drivers, we have 2 images one for staff and student which can be added to a particular task sequence.
I need to create a portable solution for cloning without the network using 2 different SCCM (System Center Configuration Manager) task sequences. At the moment I go through the usual steps of creating a boot media via the Configuration manager, but there seems to be know way to create a script that changes the task media on the fly so you can select which OS image.
I was looking at a possible solution using YUMI (a Usb boot tool) but each bootable image requires an ISO. The task sequence image is around 8GIG.
We use SCCM 2007. (Still awaiting for a budget to upgrade to 2012 :) )
It sounds like you want to boot two different .WIM images.
Out of the box, I haven't found any tool from MS that will allow this. I have gotten around this discrepancy by renaming the .WIM I want to use to BOOT.WIM in the \SOURCES directory.
That is the name of the .WIM that gets used by all the default settings. You have to rename the file before you attempt to boot from the USB device, but it doesn't take long and could be scripted without much effort.
Theoretically, it should be possible to configure the BCD on the USB device (\EFI\MICROSOFT\BOOT\BCD or BOOT\BCD, depending on how the computer is configured to boot) so that you could choose which .WIM to use at boot time without the need to do any messy renaming. I haven't gotten this to work yet (mostly due to lack of time/urgency), but I did write down what I had done so far. I found some useful information about booting to .WIM's from windowsitpro.com.