Need help Direct connect Lab - equipment interfacing
Elanchezhiyan
Little progress I have made on equipment interfacing.
Backgound:
Vitors Eci -
supported protocol ASTM, Kermit, and Upload only mode.
connector - RS232 25DB M
I have created RS232 25DB M to 9DB F NULL modem cable for connecting
the Instrument with LIS(VistA) direct connect approach.
I'm able to receive the data on Upload only mode, but data starting
from nov. 2009 not the current data. Since there is limitation on the
service engineer I switched to ASTM protocol.
According to Vitros Eci Specification the connector for ASTM protocol
should be of 25DB M to 25 DB M DTE to DTE which is not applicable for
the resource LIS computer's 25DB pin mapped to /dev/lp0.
When i'm trying to open
GTM>s x="/dev/lp0"
GTM>o x
%GTM-E-UNIMPLOP, Unimplemented construct encountered
so I made 25 to 9 pin cable and used /dev/ttyS0 and configured the
system as follows,
1. Created entry in device file #3.5 " Vitros Eci" for serial port
$I --- > "/dev/ttyS0"
Type ---> "other"
3. Created entry in #62.4 Vitros Eci
and pointed the Direct Device field to "/dev/ttyS0" ( Vitrso Eci )
and program to LAPORT33
4. Started background job using BKGND^LAXSYMU program for Axsym
Machine.
hoping it doesn't matter since i'm poinitng the device to Vitros Eci.
5. with ^LA("D33",0)=0 global I could log the incoming and outgoing
information
6. The Vitros given out <ENQ> and as a reply the vista send out <ACK>
but in turn Vitros sending out <EOT> instead of Results frame.
I have done the loop back testing on vitros Eci side and VistA side
also.
I trying to figure out the problem.
if there anybody tried out the same, I request to give an idea to
proceed further.
Am I in right track?
Regards,
Elancheziyan K.
Elanchezhiyan
Regards,
Elancheziyan K.
OHUM
OldMster
connections anymore.
After the ECI sends the ENQ, how much time elapses until it sends the
EOT? Is it immediately after the ACK is sent back from Vista, or is
there a delay? If there is a delay, it is probably that the wire
connecting the 'send' pin on the Vista side isn't correctly connected
to the 'receive' pin on the ECI connector, so the ECI never sees the
ACK.
If it is immediate, then that would indicate to me that the ECI didn't
have any results to send, although I didn't think it would ask for the
session if that was the case. If you are using the resend function,
did you select some results to send first, or did you just click the
transmit button?
I prefer to use a network single device connector to connect
laboratory instruments rather than direct connections. These devices
convert the serial connection on the device to an ethernet connection
that allows a TCP connection. This allows easier moving/relocation of
the instrument without the wiring hassles - most IT people can deal
with an ethernet connection today, but RS-232 is a mystery to most. I
prefer the UDS1100 from Lantronix ( www.lantronix.com ), but devices
from other manufacturers have similar devices. I like the UDS because
it has a 25 pin DCE connection like an external modem would have, so I
can send the technician to the nearest computer/office supply store to
get a standard premolded modem cable to connect the device to the
instrument. I then Velcro the device to the machine so it is obvious
it should stay with/move with the machine.
Mark
Elanchezhiyan
I have tried TCPCOM software from taltech to redirect the information
from instrument to the VistA server by having intermediate PC.
Instrument not receiving any signal from VistA through same path.
"If there is a delay, it is probably that the wire
> connecting the 'send' pin on the Vista side isn't correctly connected
> to the 'receive' pin on the ECI connector, so the ECI never sees the
> ACK.
> "
I have done the loop back test on the both side by connecting the Tx
and Rx pin. Since this my first Bidirectional equipment interface
experience I may be doing some mistake. Let me try again and find the
possibility of procuring UDS1100 through the client. If I succeed,
will try to post back my result.
Thanks for your information and help.
On Mar 27, 6:27 am, OldMster <msi...@verizon.net> wrote:
> Sounds like you are making progress, although I don't do direct serial
> connections anymore.
>
> After the ECI sends the ENQ, how much time elapses until it sends the
> EOT? Is it immediately after the ACK is sent back from Vista, or is
> there a delay? If there is a delay, it is probably that the wire
> connecting the 'send' pin on the Vista side isn't correctly connected
> to the 'receive' pin on the ECI connector, so the ECI never sees the
> ACK.
>
> If it is immediate, then that would indicate to me that the ECI didn't
> have any results to send, although I didn't think it would ask for the
> session if that was the case. If you are using the resend function,
> did you select some results to send first, or did you just click the
> transmit button?
>
> I prefer to use a network single device connector to connect
> laboratory instruments rather than direct connections. These devices
> convert the serial connection on the device to an ethernet connection
> that allows a TCP connection. This allows easier moving/relocation of
> the instrument without the wiring hassles - most IT people can deal
> with an ethernet connection today, but RS-232 is a mystery to most. I
> prefer the UDS1100 from Lantronix (www.lantronix.com), but devices
OldMster
Vista server to do the direct connect with? If it is an RS-422 rather
than RS-232 device, it will have two separate grounds - one for the TD
line and one for the RD line. On the instrument RS232 connector, both
of these need to be connected to ground pin (pin 7 since the ECI has a
25pin connector). If only one of the grounds is connected, it will
only work reliably in the direction that the ground is connected for.
You may get sporadic data on the ungrounded line, but it will not be
reliable. Learned this the hard way the first time I used a Lantronix
terminal server with RS-422 connections. Go on site, works fine, as
soon as I leave, stops. go back, switch wires around, works. Leave,
quits. Once I figured out that both grounds had to be connected, it
worked perfectly.
Mark
OldMster
is RS-232.
Another good debugging technique is to make a cable that eliminates
all hardware handshaking, in case one end or the other is not
configured correctly. To make the cable only connect the TD, RD and
signal ground lines between the two connectors, 2<->2, 3<->3, 5<->7 in
your case, since 2 & 3 reverse between 9 & 25 pin, and signal ground
is on 7 and 5 respectively. On the 25 pin connector, connect pin 4 to
pin 5, and connect pins 6, 8 and 20 together. On the 9 pin connector,
connect pins 7 and 8 together, and pins 4 & 6 together. This way each
end of the connection is supplying it's own handshake signals. Unless
you can configure software handshaking, this shouldn't be used for
production, since the connection has no handshaking and can overrun,
but for initial debugging/connection testing it is very useful.
Mark
K.S. Bhaskar
boxes. Once we got the connection working with a breakout box, it was a
simple matter to make up a cable with the right pin out. I don't know if
breakout boxes still exist except in museums and landfills, but they were
incredibly useful.
-- Bhaskar
GT.M - Rock solid. Lightning fast. Secure. No compromises.
On 03/30/2010 04:50 PM, OldMster wrote:
> Sorry, just noticed you said 9 pin to 25 pin adapter, so probably it
> is RS-232.
> Another good debugging technique is to make a cable that eliminates
> all hardware handshaking, in case one end or the other is not
> configured correctly. To make the cable only connect the TD, RD and
> signal ground lines between the two connectors, 2<->2, 3<->3, 5<->7 in
> your case, since 2 & 3 reverse between 9 & 25 pin, and signal ground
> is on 7 and 5 respectively. On the 25 pin connector, connect pin 4 to
> pin 5, and connect pins 6, 8 and 20 together. On the 9 pin connector,
> connect pins 7 and 8 together, and pins 4 & 6 together. This way each
> end of the connection is supplying it's own handshake signals. Unless
> you can configure software handshaking, this shouldn't be used for
> production, since the connection has no handshaking and can overrun,
> but for initial debugging/connection testing it is very useful.
> Mark
_____________
The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.
_____________
OldMster
I have two or three laying around here somewhere.......... A little
dusty.
I once even cobbled together a couple of devices that I could hook on
each end of a long wire run and it would tell me by which LED lit up
which wire was which. Good times, don't miss them a bit..... TCP/
ethernet is so much better!
Mark
Elanchezhiyan
I may not be allowed to work on instrument for some time. I will
update the outcome.
Regards,
elanchezhiyan K.