I am trying to set up a potentiostat Xtralien by Ossila with LabView.
The way the instrument works in a string-in, string-out, so far so good.
The built-in code examples that are provided by the manufacturer contain firstly a string-in, string-out LabView program and secondly a preliminary console to record an I-V sweep (https://www.ossila.com/pages/basic-xtralien-commands-in-labview, https://www.ossila.com/pages/xtralien-x100-command-list). In the string interface, I can enter 'CLOI hello' and the device responds 'hello world', so far so good. If I proceed any further and send i.e. a 'smu1 measurev' command connecting to some photodiode, I just receive a near-zero value back, setting 'smu1 set voltage 0.5' or similar does not lead to an output voltage either. Running the sweep program over said photodiode gives noise in the µA range.
EDIT: All involved hardware components were double-checked.
Where am I doing something wrong? Is the error arising from communication errors or...? Has someone experienced this so far?
Received the answer from the Ossila support. The Xtralien X200 drivers were recently updated (http://files.ossila.com/source-measure-unit/Ossila-X200-SMU-Instr.zip), and you need to switch on each SMU channel sperately. This was implemented in a subVI in the Instrumentation -> X200.
Hope I helped all who get a similar problem in the future!
Related
I have chipKit uC32 (PIC32MX340F512H) ,chipkit BasicIOShield and PICkit3
programmer all from the Microchip.
I'm using MPLABX IDE.
Since I'm very new to this so I didn't know where to start I have searched and look at the web and find only tutorial which using MPIDE which I'm not allowed to use in my project.
I have read the Reference manual and Data sheet for and make test project but any way the uC32 Board refuse to recognize the BasicIOShield and I was unable to connect this two together.
Any tips and link would be great. Thanks in advance.
In the Basic IO shield Reference manual stated that you should follow some step in order to make the ChipKit to talk to the basic IO shield.
Power on sequence
Apply power to VDD.
Send Display Off command.
Initialize display to desired operating mode.
Clear screen.
Apply power to VBAT.
Delay 100ms.
Send Display On command.
Power off sequence
Send Display Off command.
Power off VBAT.
Delay 100ms.
Power off VDD.
The shield is using SPI2. The following registers are used
RF4, RF5, RF6 and RG9
Also you must change the jumper in the uC32 from LED4 to JP4 and JP8.
in the Appendix B of the reference manual of the basic IO shield is an example code which is useful.
First, appreciate you giving this a look. I have an ancient piece of software that writes old Linear PCMCIA cards. In my case, I want to use it in a specialized piece of gear called a Tech2. The software in question is called Memory Card Explorer. Now, I know for a fact it works in Windows XP with Native PCMCIA slots. However, I have a slot that is built on a Dual Systems adapter (basically an Expresscard to PCMCIA adapter).
The issue arises when following the instructions on installation issues, the program refuses to locate the Dual Adapter. Here's the example given in the manual:
"Use a similar address to the PCMCIA adapter. That address can be found using msinfo32.exe.
Eg: if the PCMCIA socket has a memory resource of F8000000 then use a MCE window command of F80D0000 using command line option of WF80D0."
So I get my adapter address which is F7FFF000 but have no idea where to add the "d" to the resource address then change it to a command. I've tried WF7FD0. Am I missing something simple in how these addresses are truncated for command line? Is there a calculator that does the conversion for you somewhere?
Thanks.
It looks like the pattern is to add 0x000D0000 to the address, take the five high nibbles of the address (which makes sense, since these sorts of addresses are typically page-aligned the bottom 3 nibbles will always be 0 on a system with 4KiB pages), and prepend 'W'. Try WF80CF.
This is the message i got when i tried to dispense money from Wincr Nixdorf ATM by using CDM320.exe which is a built-in tool of the ATM. In general, the safe door of an ATM must be closed for dispense to be done successfully. I don't know where this message has come from!
I wrote a source code for dispensing via XFS 3.00 API. It works on GSS ATM, but it doesn't work on the Wincor ATM.
How can i make sure that everything in the Wincor ATM is properly configured and working, like SPI, MSXFS.DLL file is good-versioned and properly works and everythings are compatible to work together? Since the CDM tester tool is not working, i doubt in the ATM itself instead of my program.
First you should check the Wincor manual(s) how to configure the CDM device to your expected behavior model.
This particular instance could indicate that the dispenser/ATM is in test mode and thus doesn't allow dispense unless the safe door is open (and possibly even the dispenser should be out of the safe).
Or maybe the error message is missing a work 'NOT' and your safe is not properly locked.
Even in this case the CDM configuration should do the trick.
PS. I don't have experience from Wincor HW so this might be totally off the mark as my experience come's from NCR HW.
I have just started on libusbdotnet. I have downloaded the sample code from http://libusbdotnet.sourceforge.net/V2/Index.html.
I am using a JetFlash 4GB Flash drive (a libusb-win32 filter driver was added for this drive).
The ShowInfo code works perfectly, and I can see my device info with two endpoints. Following is the device info from pastebin
http://pastebin.com/2Jdph6bY
However, the ReadOnly sample code does not work.
http://pastebin.com/hNZaEt8N
My code is almost same as that from the libsubdotnet website. I have only changed the endpoint that UsbEndpointReader uses. I have changed it from Ep01 to Ep02, because I read that the first endpoint is a control endpoint used for configuration, access control and similar stuff.
UsbEndpointReader reader = MyUsbDevice.OpenEndpointReader(ReadEndpointID.Ep02);
I always get the message "No more bytes!".
I thought that this is because of the absence of data, so I used the ReadWrite sample code.
http://pastebin.com/NiN5w9Jt
But here I also get "No more bytes!" message.
Interestly, the line
ec = writer.Write(Encoding.Default.GetBytes(cmdLine), 2000, out bytesWritten);
executes without errors.
Can pen drives be used for read write operations? Or is something wrong with the code?
A USB thumb drive implements the USB mass storage device class, which is a subset of SCSI. The specification is here.
You're not going to get anything sensible by just reading from an endpoint - you have to send the appropriate commands to get any response.
You have not chosen an easy device class to begin your exploration of USB - you may be better starting with something easier - a HID class device, perhaps (Mouse/Keyboard) though Windows does have enhanced security around mice and keyboards which may prevent you installing a filter.
If you meddle with the filesystem on the USB stick while it's mounted as a drive by Windows, you'll almost certainly run into cache-consistency problems, unless you're extremely careful about what kind of access you allow Windows to do.
I use NSTask to run my helper application. On 99% one my customer systems this works fine, but two got back to me letting me know it doesn't. One of them was nice enough to let me look into the issue per remote desktop.
I tried a lot of different NSPipe/NSFileHandle combination for StandardOutput/StandardError to make sure the problem is not related filling up these buffers. Example 1 and 2. My guess is that it is not related because it works fine on so many systems and _dyld_start is too early on in the application lifecycle to fill up StandardOutput/StandardError.
Other notes about the problem:
Launching the helper app from the terminal works fine.
Attaching and detaching the gdb on the stuck process and after-worth it works fine and when it finished NSTask picks up work after -waitUntilExit.
Using fork(2) and execv(3) instead of NSTask is able to launch and run the helper fine.
The parent process is sandboxed but I think previous reports where non-sandboxed on Mac OS X 10.6/10.7.
Screenshot of the process Sample from Activity Monitor:
Any clues or debugging tips to figure out why the helper is stuck in _dyld_start are welcome!
Since nobody answered, I am throwing a few ideas. Maybe one of them is the answer – only guessing – but since clues and tips are welcome, you could take a look at:
the list of the loaded libraries in the crash dump (there may be a clue there)
any error that would happen in the child process (after the fork). However, I see why it could be difficult to get back any post-fork error.
If I recall correctly, NSTask calls posix_spawn(2). This may be a clue, since using fork(2) and execv(3) seems working, you could focus on the differences between NSTask and the non-blocking alternative. Clearly, something is happening at the very beginning that prevents the child from executing properly.
Are you sure it is stuck and not crashed? As far as the user could tell, your app your app wouldn't look like it crashed. Only the child process would crash.
As a last resort, you could try to look for any Mach exception occuring (if
any, that would mean an error, which you wouldn't be able to
recover anyway. But it would provide valuable clues nonetheless).
You can tell willing custommers to send you their sysdiagnose. To this goal, ask them to hit Command + Option + Control + . + Shift to wait a few minutes. Soon after, their finder should pop a window to reveal a file named: sysdiagnose_timestamp_.tar.gz. Kindly ask them to mail it to you. Mine is around 5 MB. More details on the sysdiagnose man page.