EBME Forums Forums Maintenance Technical Assistance Communication with Alaris/Asena Syringe Pump

I suspect that's Bruno's problem, right there!

So much, then, for "progress".

What commands are you sending to the pump, are you initialising the port with some precursory commands before telling it to send the serial number?

RTS/CTS/ACK etc?

I'm also trying to get an Alaris pump to work. Does anyone know if a special cable is needed?

Also can anyone confirm the flow settings? eg RTS/CTS or XON/XOFF or none?

I'm currently trying to use the string earlier up the thread, do you just send this:

21 49 4E 46 7C 34 39 36 31 0D

Or are slashes needed? Or remove all the spaces?

Welcome to the forum, Matthew.

I just thought I had better say "Hi" so you don't feel we've ignored you!

Talking about this stuff can be (is) a bit tricky unless everyone is "singing from the same hymn-sheet"*, as it were.

So ... assuming you have scanned through the earlier posts on this thread ... do you have all the references mentioned?

Then, what exactly are you trying to do? And what have you managed to achieve so far?

Lastly (and sadly), I could be wrong but I believe that later (software) versions of the Asena syringe pump may not permit playing about like this.

Meanwhile:- a "straight" 9-pin D-sub serial cable; no slashes, but with spacing just as you have shown (assuming that those hex codes are correct).

* With due tip o'the hat acknowledgement to Ed Bennett.

Hi Geoff.

Thanks for the kind welcome & quick response. I have a copy of the Alaris User manual, the Technician manual and the Asena Comms Protocol. It seems fairly straight forward really, but I just can't get it to work. I've read this thread in full, it's been really useful.

Cablewise, I have a normal USB to DB9 serial port adaptor cable, which is cabled directly to the back of the Alaris pump. I'm using the settings from the User manual:

38400 baud
1 start
1 stop
no parity
8 data bits

and I'm not sure about flow control. In the manual it says there's no Hardware flow control, so that's no to RTS/CTS I assume. I've been trying with 'none', but also with XON/XOFF.

So far I've been able to work out how to get the pump into technician mode. Then I've used code XXX so I can enable the Nurse Call and RS232 Hardware. So I assume that I've got a version of software which will allow this. So then I fire up a serial terminal program (I'm using Ubuntu Linux 13.10) like Kermit or GTKTerm. Paste the command in:

21 49 4E 46 7C 34 39 36 31 0D

But nothing happens. No response. Not even some garbled messages. Ideally I'd like to use the SYRFORCE command, which would be:

!SYRFORCE|1E6F

and in Hex:

21 53 59 52 46 4f 52 43 45 7c 31 45 36 46 0D

I'm sure once I've got the INF command working, then getting the other ones going will be fine. I don't want to do the remote config, just poll the device for some basic info.

Thanks in advance, Matt

Sorry for not replying a bit sharper, Matt ... but I was staring at this for a good hour (you know, the way you do) ... then I was disturbed by a 'phone call. Then I badly needed a cup of tea. You know the sort of thing.

OK, let's try a bit of "rubber ducking" here:-

Can you explain (break down) the command string you've mentioned there? I seem to recall that the pump serial number* is involved in this process somewhere ... if (when) it needs to be entered, are you sure you've got it correct?

My only other thought at this stage is the USB to 9-pin serial connection. Are you sure it's "getting through" (there - and back)? As has been mentioned before in the thread, us Old-Timers would have preferred a good old-fashioned "DOS type" serial connection.

Keep going Matt. Just imagine that feeling of euphoria when you finally make the breakthrough!

* It may have been just the length of the serial number.

Perhaps I'm totally misunderstanding all this ... but isn't the (decimal) "4961" portion a result of applying the CRC "security function" ... which interogates the pump's serial number to kick out (return) a unique "security code", which is then the one needing to be fed in? There has to be some sort of "gate" to be unlocked before free communications are permitted.

In other words, doesn't each pump need a different code following the "INF" command? And that code is returned in advance by applying (what is called here) the "CRC-CCITT function"?

Geoff - thanks for the reply.

The docs say that you only need the serial number if you're looking to do remote config. I'm not, just trying to get the Syringe Force pressure from the device.

I ended up trying a different program for the serial connection. Also you don't need to use hex, or at least not on the put that I've got. Just using GTKTerm and then sending:

!SYRFORCE|1E6F

Got this back:

!SYRFORCE^1.382^kgf^1943^1748^mV^13727^uA|80AD

Which is exactly what I was looking for. So you just use the CRC-CCIT to encode the command, put the ! at the start and the | in the middle and that's it. Also:

FLOW control is NONE. But it will work with RTS/CTS as well. So my settings are:

38400 baud (or 38.4k)
Parity - none
Command bits - 8
Stopbits - 1
Flow control - None

As an aside, I see someone has edited my post. Just wondering why?

Excellent! Well done.

So the "1E6F" segment you have used are just ASCII characters, then? In the "protocol" that portion is known as the "Frame Check Sequence" (or so I believe), that would normally expect four hexadecimal characters.

In this case:- 31 45 36 46 (if I'm not mistaken).

But ... how do (did) you generate those characters? By applying "SYRFORCE" into the CRC-CCIT function? We had better make it clear for the next guy who might want to have a go.

Meanwhile, it seems that the "answer" there was using GTKTerm. Could a Windows user expect similar success using HyperTerminal, I wonder? Or even Docklight ... or Termite (freeware and [or] Open Source stuff is always preferred)!

Maybe I'm being a bit thick (!), but I'm still trying to fathom the "80AD" at the end of the returned string. Wouldn't we be expecting a CR (hex 0D) there?

Editing is "not my department", BTW. But I suspect it was done to shield the config access code (which does, after all, open the door to 700 or so parameters)! Even though, perhaps I should add, it did get a mention earlier in the thread!

Matthew,
I edited it to remove the code number, it says that in the "Reason for edit" comment (in small print) at the bottom of the message.
It is not a good idea to put access codes on this open forum where anyone can read it. They might then be able to mess around with equipment in an inappropriate way. And there are a few weird people out there who like to mess with people under their care.
Robert