Definitive substitute for Parallel Port bit toggling?

Hi,

I have joined the ranks of Windows users needing a substitute for sending digital control bits out of Windows on machines with no parallel port. Is there a definitive preferred solution to this?

I assume the solution will be USB-based. We cannot simply insert a parallel port or DIO board due to form factor / space limitations. I need to reserve audio output for, well, audio output. The solution needs to be clean (adpater cable OK, breadboard not). The instrument receiving the digital bits simply samples the 16-bit word upon any bit transition; it does not communicate back to the PC in any way.

Is this simply a matter of plugging in a USB-to-Parallel port adapter cable (Sabrent USB-to-Printer cable)? Will Matlab or Simulink work with it if the connected device is, as in this case, just a dumb listener?

Thanks!

Answer 1

[Walter Roberson]

I think you are likely to have a lot of problems with this.

USB, even run through a converter cable, is managed by a controller which runs a defined cycle of operations using slot times. The output to any one device can only occur when it is that device's turn -- and part of the controller cycle is always spent listening for requests from other devices (remember, USB is plug and play so the fact that you only had the parallel cable attached to the controller 25 nanoseconds ago doesn't mean that there isn't a video-camera or hard-disc ready for action now that has to be scanned for...)

USB is a serial protocol, always. The connector only has one data output line. USB connectors are only 4 or 5 pin. Therefore it is impossible for the USB controller itself to latch output lines. The chip built in to the USB - parallel cable might latch lines, but you would need to test that thoroughly.

Parallel port communication was not designed to latch lines: the parallel bus cycle shows the lines being expected to drop to neutral between write cycles.

You indicate that the receiving instrument samples the 16 bit word, but parallel only defines Data0 to Data7, along with at most 4 output control lines (including strobe.) If you were thinking of using some of the control pins to carry data, then you would need to test the adapter well to be sure that it has the same ideas about acceptable use of those pins. And if not... where are the other 8 bits going to come from?

Then you get in to questions about signal latencies and degree of control of the duty time of the signals.

MATLAB will be pretty much eliminating parallel port support within a small number of releases: Windows 7 wraps I/O ports in so many security layers that it is not possible to get reasonable performance anymore.

[John Simeral]

Thanks, Walter. I've been going over your many related posts and I realize they lead to the same conclusion.

Ultimately, I am searching for a method to provide synchronization signals among multiple sources running on different clocks (mostly different PCs). The best synchronization obviously requires the lowest latency after each source tries to strobe out its sync signal (whatever that turns out to be), including driver delays, Windows OS interference, etc. It does appear USB will be a disappointment.

We've been having each source drive some bits on the parallel port using io32 (solution 1-1MOJMJ) with satisfactory results, but now without adding DIO hardware I may not do much better than occasional UDP packets sent to a common listener?

Cheers.

[Walter Roberson]

In the old days, we would use Genlock, http://en.wikipedia.org/wiki/Genlock

Is everything networked? If so you might be able to use NTP time synchronization, http://support.microsoft.com/kb/307897 would probably get you sync on the order of 1 ms, http://www.ntp.org/ntpfaq/NTP-s-algo.htm#Q-ACCURATE-CLOCK

Some of the better A/D and D/A cards have simple lines to chain synchronization between boards.

[Walter Roberson]

Were you thinking of having a sync master, or would several (all?) of the devices be able to trigger re-sync ?

How about the "sample now" triggers? Master / slave? Or a shared bus of some sort with different devices being able to emit triggers? If shared bus, are there multiple trigger "channels" used to signal different subsets of the devices? If so, how many independent subsets?

I'm just trying to get a better mental image of the architecture and needs.

[John Simeral]

Thanks for the information & questions.

The system is a closed-loop control system with different PCs collecting, processing, and/or generating different data streams, displaying graphics, etc. Although some data may be collected from non-PC based devices (digital video camera, for example), the truly critical items are all Windows PCs running Win7 and are networked on a private LAN.

Some run Matlab, some run Simulink (with a Real-Time subsystem), and some run other software (game-engines, face tracking or motion capture, internet access, etc). Most send out UDP data packets to our core Simulink model, but others just log their data to their local machine, timestamped with their local machine clock, for off-line analysis. We are headed toward Windows RT target or xPC for some models.

The main need is to, off-line, re-sync the data from the different machines. Reliable 10 ms accuracy would be acceptable; 1 ms accuracy would be perfect; finer grain is overkill. If UDP packet delays (including packing, delivery, and unpacking) always stayed in that range then the job would be mostly done.

For on-line "real-time" computations we just merge data from the different sources as fast as it arrives at our core Simulink model, since delaying any data for the sake of synchronizing it would have disadvantages.

Our setup requires laptops or small form factor PCs with only a slot or two (used for other purposes such as CAN bus), so DIO cards are out.

NTP actually looks at first glance like a potential solution, particularly if it uses a second low-traffic Gb LAN, away from the dense UDP data activity. It also looks like there may be some visibility via statistics files that would allow me to log and review clock changes for sanity checking. And, it looks like it would still work if we migrate some of the systems to Linux. What to do with xPC?

[John Simeral]

In fact, we might want more direct control over the sync process. Since we don't actually care about changing system clocks, but rather just need to stimate their instantaneous offsets, the preferred solution may be to implement a simplified NTP-like send/receive mechanism to estimate UDP latencies between one of our PCs ("master") and the others.

Answer 2

[Deepa Darshan]

hi all,

I am doing an project based on real time data collection via lan. though we have toolboxes and blocksets for doing this. since, i supposed to do it with m-file. anyhow, i tried it well. but, getting some errors and warnings. it will be very helpful, if you some experts suggest me a right way.

and my code is,

interfaceObject=tcpip('192.168.1.1',80);  %this is my server IP address.
figureHandle = figure('NumberTitle','off',...
    'Name','Live Data Stream Plot',...
    'Color',[0 0 0],...
    'CloseRequestFcn',{@localCloseFigure,interfaceObject});
axesHandle = axes('Parent',figureHandle,...
    'YGrid','on',...
    'YColor',[0.9725 0.9725 0.9725],...
    'XGrid','on',...
    'XColor',[0.9725 0.9725 0.9725],...
    'Color',[0 0 0]);
xlabel(axesHandle,'Number of Samples');
ylabel(axesHandle,'Value');
hold on;
plotHandle = plot(axesHandle,0,'-y','LineWidth',1);
bytesToRead = 500;
interfaceObject.BytesAvailableFcn = {@localReadAndPlot,plotHandle,bytesToRead};
interfaceObject.BytesAvailableFcnMode = 'byte';
interfaceObject.BytesAvailableFcnCount = bytesToRead;
fopen(interfaceObject);
pause(3);
snapnow;
 function localReadAndPlot(interfaceObject,~,figureHandle,bytesToRead)% herr, this function is not supporting. how sholud i do then?
data = fread(interfaceObject,bytesToRead);
 function localCloseFigure(figureHandle,~,interfaceObject)% here also...
fclose(interfaceObject);
delete(interfaceObject);
clear interfaceObject;
delete(figureHandle);

[Walter Roberson]

This should be a new Question, please.