Hi Christopher!
I am trying to set up my experiment (which works just fine with a Gamepad), using the ITC-18 device. I connect the ITC-18 via a USB-18 connector for which I downloaded the recent drivers (and of course the mWorks-Server runs in 32-bit mode).
The first time I start an experiment (e.g. your ITC-18 Test-Routines), it initializes without any errors. There is, however, no reaction of the device (apart from the Ready-LED becoming green). I tried everything to get it working, including to test several ITC-18s and USB-18s and to double-check the wiring, but it just would not react. And it get’s worse: After unloading an experiment no other experiment can be load without giving me an error (ERROR: Can’t start iodevice (sITC) and no alt tag specified). I have to restart the server in order to get it working again. The Ready-LED of the ITC, once green, also never goes off.
… And even worse: When I try to plug out the USB-Cable to the USB-18 to reset the device, it will then stay high on TTL0. The only way to solve this is to wait something like 5 minutes before reconnecting the USB-18. As I stated above, this happens with several Computers, ITC-18s and USB-18s.
What’s going on? I would appreciate any hint that helps me solve this issue!
Best regards,
-Philipp
Just a quick note on this discussion, mostly for Chris’s benefit: I just recently fixed a shared_ptr reference loop related to IODevices (commit: 3c3f5cbfa53a35923db5). This might explain why unloading the experiment does not get him back to a clean state. We were having a similar problem recently with a different IODevice.
Beyond that, can’t help, don’t have any ITC18s. Good luck!
– Dave
Hi Philipp,
Unfortunately, I’m currently out of the office and won’t be back until Monday, Nov. 15. Until then, I’ll be able to provide only a limited amount of help .
First, can you send me a copy of the experiment you’re trying to run? There may be an error in it that’s preventing you from getting data from the ITC.
Second, I recommend downloading a current nightly build and trying your experiment again. The current nightly build contains the bug fix that Dave mentioned, which may solve part of your problem.
Thanks,
Chris
Hi Chris and Dave!
Tank you for your quick replies!
I will try the current nightly build later today and I will report back if that changes anything.
I tried to run several different experiments to test the ITC, but even the ITC_TTL_Pulse_high_example located under mw_examples/Tests/IODevice/ITC18 in the repository does not work.
-Philipp
Update:
Using the nightly build did not change anything. The server still has to be restarted, the lights don’t go off and the errors are the same.
Sorry,
Philipp
I just came off the phone with the HEKA-Support. They suggested that I test the device using a 32-bit Windows machine, which I then did.
Apparently, there seems to be an issue with the driver and the Digital-IO ports on the USB-18. These ports initialize in a random state once the device is connected and can not be changed afterwards.
I don’t know how you did this in your example experiments (you always refer to the asynchronous TTL-Outputs, which are the strangly behaving ones). But there is another possibility to get the outputs working: why don’t we use the synchronous ports of the ITC-18 (which are also the only available outputs when the device is connected via PCI-card)? Is there a way to talk to those ports?
Thanks,
Philipp
So… I managed to find a workaround for the problem:
To begin with: For some strange reasons the first couple of TTL-Output-Ports do not work, but ports with higher index numbers do. For now I just use the last one (15) which works just fine. I am not sure at which port number the ITC starts working, but I am certain that ports 0 and 1 do not respond, while 14 and 15 do. TTL-Inputs work just fine.
Anyway, after running an experiment the ITC can not be reinitialized again before the server application is restarted. It is however not necessary to disconnect the USB-18 to reset the device (such as the Active-LED would also go off). The inverse, namely disconnecting the device to reset it and then trying to load another experiment does also not work. So I guess it is not properly shutdown after finishing an experiment.
I would be happy to help by describing the problem further (after the 15.)
Philipp
Hi Philipp,
I’m back in the office and have been investigating your problem.
I’ve reproduced the problem of needing to restart the server after unloading an experiment that uses the ITC-18. This is a bug, probably similar to the one Dave fixed recently for another I/O device. I’ll investigate some more and try to come up with a fix.
I’ve also reproduced the issue with the “Ready” light never going off. This may be a result of the previous problem, in that the device is never shut down properly.
As for the device not generating output, I think the problem is that you’re looking for the signal in the wrong place. An ITC channel with capability ITC18_TTL_ASYCH_OUTxx generates an output on one of the 16 auxiliary output lines. These lines are accessed via the 34-pin IDC connector on the far right of the device’s rear panel (item 9 in Figure 3 in the ITC-18 user’s manual. I’ve verified that the ITC_TTL_Pulse_high_example produces the expected output on auxiliary output channel 0.
My understanding is that you’ve been trying to get the output signal from the 68-pin “Digital I/O” connector on the USB-18. Is that correct? If so, you’ll need to use the 34-pin aux. output connector instead. Assuming I’m reading the manuals correctly, it appears that the I/O channels on the USB-18 are completely independent of the ITC’s I/O channels. The interface library provides separate API calls for accessing the USB channels, and the current MWorks ITC-18 plugin does not support them.
The plugin also doesn’t support the synchronous TTL outputs or the DAC outputs on the ITC. It could be extended to support them, but I guess there hasn’t been much demand for it. I assume the auxiliary outputs have been sufficient for most folks’ needs.
Please let me know whether this solves your output-generation problem.
Thanks,
Chris
Hi Chris,
tank you for your reply!
In the beginning, I indeed looked for a signal at the Digital I/O on the USB-18, but only because I couldn’t get a response from the auxiliary output connector (which I tried beforehand). After looking at your code it then became clear to me that, at least in principle, the signal should be on the aux. lines, but it wasn’t. Now I discovered that, for my two ITC’s, ports with a two-digit index number work just fine (so everything from 00 to 09 doesn’t give me output). As I need only one output-port to connect my juicer to it now works with port 15, even though I find all this to be rather odd. Anyway, monkeys don’t seem to care ;).
As for the light never going off I can report that the same behavior occurs when I try the EPC-Master application from Instrutech. This one initializes the ITC and then lets me set the aux. ports (of course all the ports work with this program). After shutting it down, however, the Ready-LED will not go off. This does not seem to be a problem, the device would re-initialize just fine the next time I try to connect to it.
Oh, and I have not heard back from Instrutech but they promised me to fix the driver so that it will support the USB-18 ports. Maybe they will also add a 64-bit support, that would certainly be beneficial for us… I’ll keep bugging them about it.
Tanks for your help!
Philipp
Hi Philipp,
I believe I’ve resolved the issue with the ITC not being shut down properly when you close an experiment. The fix is in the current nightly build. Can you try it out and verify that you no longer need to restart the server between experiments?
Also, the MWorks ITC-18 plugin now turns off the “Ready” light when it releases the device. This should give you an easy way to check that MWorks has shut down the device properly.
I discovered that, for my two ITC’s, ports with a two-digit index number work just fine (so everything from 00 to 09 doesn’t give me output). As I need only one output-port to connect my juicer to it now works with port 15, even though I find all this to be rather odd.
That’s very strange. On the ITC I use for testing, I’m able to use the first ten ports. Presumably it’s not a hardware issue, since the ports work with the Instrutech application. Let me think about this some more.
Oh, and I have not heard back from Instrutech but they promised me to fix the driver so that it will support the USB-18 ports. Maybe they will also add a 64-bit support, that would certainly be beneficial for us… I’ll keep bugging them about it.
Yeah, 64-bit support would be great. I asked them about it a while ago, and they said they’re working on a 64-bit Windows driver, after which they’d consider one for the Mac. I guess we should both keep bugging them 
Chris
Hi Chris,
I tried to download the current nightly build, but I get the error that I don’t have permissions…
Philipp
I tried to download the current nightly build, but I get the error that I don’t have permissions…
Sorry, the permissions got messed up somehow. You should be able to download it now.
Chris
works like a charm, thank you !!