NE 500 syringe pump

Support
1

Hi Chris,

I’ve been trying to get the NE500 syringe pump to work, but without much succes.

  • I’m using a brand new NE500 syringe pump, which works correctly when tested on a Windows PC running one of their own programs called “syringepumpproV1”

  • I connect the pump to an imec running Yosemite and MWorks 0.6 (the nightly build always crashes when I load the server, but that’s another issue) through a starTech 1Port RS232/422/485 (which responds to pings)

  • MWorks gives me the error message: “Did not receive a complete response from the pump”

I tried to track the problem down by compiling a version of the plugin with extra debug messages. I found that the pump almost never returns a message: the return value from the recv() function is almost always empty. On some rare occasions I get a “$” or “n” as return value. Furthermore, the plugin never makes a new connection to the device: the connect() function in “connectToDevice()” never return zero (zero is needed for connection) but always (two times within the while loop) a return value of -1, with EISCONN as error message. So the program seems to think that there is already a connection and never makes a fresh connection for some reason. Before breaking with the EISCONN error, it always makes 1 loop in which there is an EINPROGRESS error (with select_err = 1).

So I suspect something goes wrong while connecting.
What do you think?

Thanks,
Bram

2

Hi Bram,

I can think of a couple things to check.

First, are you sure the StarTech is configured correctly? To talk to the pump, the serial I/O settings must be as follows:

  • baud rate: 19200
  • parity: N
  • data bits: 8
  • stop bits: 1

I think you can leave the remaining settings at their defaults. (For reference, I’ve attached a capture of my StarTech’s setup screen.)

If that all checks out, then you may need to use the recently-added response_timeout parameter (details). Try starting it at a really large value (like one second), and then see how far you can bring it down while maintaining reliable connectivity. (Note that the default value is 100ms.)

If neither of those suggestions help, then I guess we have a new pump problem.

the nightly build always crashes when I load the server, but that’s another issue

Have you recompiled all your custom plugins against the new nightly? If yes, then can you please open a new discussion describing the issue (and include the MWServer crash report)?

Thanks,
Chris

3

Attachment: startech_config.tiff (108 KB)

4

Hi Chris,

Thanks for your quick reply.

You were right about the baud rate. It was never saved to the correct value. I’ve learned that if the pump is still connected to the starTech, the startTech does not save its values. Disconnecting the pump did cause the starTech to save.

I also noticed that a longer response-timeout, for us ~400ms, increased the reliability of the connection.

With these changes the pump seems to work correctly now.

Also, the crashes from the new nightly were caused by our own plugins not being compiled against the new nightly. That’s also solved now.

Thanks a lot for your help.

Bram

5

Hi Chris,

I was just making some measurements with the NE 500 plugin and noticed that the “Flow Rate” gets set twice: 1. When initializing the pump, 2. When dispensing.

If I remove the “RAT” command from the “dispense” method, the program seems to work fine, and this small change decreases the time of a “dispense” by about 80ms.

Given that we will use the same “rate” throughout a session, can you think of any issues that might occur when I remove the “RAT” command in the “dispense” method?

Thanks,
Bram

6

Hi Bram,

Given that we will use the same “rate” throughout a session, can you think of any issues that might occur when I remove the “RAT” command in the “dispense” method?

Based on my own testing, I agree that everything seems to work fine when you omit the subsequent RAT command, so it’s probably OK to remove it. Probably we should send all the pumping commands (RAT, VOL, and DIR) in initializePump, and then re-send them in dispense only if the values have changed.

Cheers,
Chris

7

Thanks Chris,

We were thinking the same: if we only retain “RUN” in the “dispense” method, the latency to actual pumping (ignoring mechanical inertia in the pump and juice tubes) reduces to ~80ms or less, compared to the 250ms right now. The reduced latency might help when training the animals (better operant conditioning). According to the manual, all data are stored in non-volatile memory, so what you suggest sounds right: only re-send them in dispense when changed.

Is this something you can do? Let me know if I can help.

Thanks a lot,
Bram

8

Is this something you can do?

Sure. I’ll try to get it done sometime next week.

Chris

9

Thanks Chris,
Bram

10

Hi Chris,

I’ve done some further tests with the NE 500 syringe pump + plugin. Apparently the pump does not accept volumes with 4 decimals. Because the default unit of volume in the plugin is the milliliter, this means that we cannot use fractions of microliters (the plugin rounds the volume to a 3-decimal number). Sub-UL precision is important for our mice training, e.g. right now 500 rewards of 1ul or 1.4ul all give 500ul, while the desired difference of 700ul vs. 500ul can be very important for the mice.

I made a quick fix by adding the following to the plugin: “sendmessage(boost::format(%s VOL UL” % pump_id) “ and now we do get sub-microliter precision.

I therefore wanted to ask you if its possible to add an option to the plugin that allows one to specify the unit of volume (monkey people probable want ML, mice people UL)?

Thanks!
Bram

11

I therefore wanted to ask you if its possible to add an option to the plugin that allows one to specify the unit of volume (monkey people probable want ML, mice people UL)?

Sure, no problem. I just started working on the changes we previously discussed, and while I’m in there I’ll do this as well.

Chris

12

Great, thanks!
Bram

13

Hi Bram,

The NE500 changes that we’ve discussed are now in the nightly build.

First, all pumping parameters (rate, volume, and direction) are sent to the pump when the experiment is loaded. Thereafter, they are re-sent only when they change.

Second, iochannel/ne500 instances now support two new parameters, rate_unit and volume_unit, which set the units for rate (UM, MM, UH, or MH) and volume (UL or ML), respectively. Either or both parameters may be omitted, in which case the old defaults are used: The rate unit is MM, and the volume unit depends on the syringe diameter (UL at or below 14mm, ML otherwise). Note that the choice of units is fixed at load time; they can’t be changed while the experiment is running.

Finally, iodevice/ne500 also accepts a new parameter, log_pump_commands, which controls whether pump commands and responses are logged as MWorks messages. If omitted or set to “YES”, commands and responses are logged as before. To disable logging, set the parameter to “NO”.

Cheers,
Chris

14

Thanks a lot Chris, this sounds great!

I will keep you posted about the results of my tests.

Greetings,
Bram

15

Hi Chris,

I did some tests with the new NE500 plugin and everything seems to work very well. More tests will be performed during the next days and I’ll keep you posted if anything comes up.

Thanks a lot, this really helps!
Greetings,
Bram

16

Great! Thanks for letting me know.

Chris

17

Hi Chris,

We have performed several tests with the new NE500 plugin and it works really well. Thanks again for your help on that.

I have one small suggestion to further improve the plugin. It would help us if we could set the reward amount (inside the pump) before we actually administer the reward. Right now these two aspects are linked together, but separating them would decrease the network traffic during the dispense command in the situation where we change the reward between trials, which happens regularly in our tasks. This then would result in slightly faster juice delivery, which may help when training the animals.

So it would be nice to have a command in MWorks that directly calls the “setVolume” method, and a separate command that directly calls the “dispense” method.

Could you help us with that?
Let me know if I can do something to help out.

Thanks a lot,
Bram

18

Hi Bram,

So it would be nice to have a command in MWorks that directly calls the “setVolume” method, and a separate command that directly calls the “dispense” method.

Sure, we can add that. Maybe the right approach would be to add a new parameter, “volume”, which takes the name of a variable from which to get the volume. Whenever a new value is assigned to the variable, MWorks will send the new volume to the pump, without starting an infusion/withdrawal. Then, when you do want to run the pump, as long as you set the “variable” parameter to the already-established volume, the volume won’t need to be re-sent.

For completeness, I’d probably make the “rate” parameter behave similarly, so that you can also change the rate without dispensing.

Does it sound like this will meet your needs?

Cheers,
Chris

19

Hi Chris,

I agree, that sounds like a good and efficient solution. Doing this for the “rate” parameter makes sense too.

Thanks!
Bram

20

Hi Bram,

So it would be nice to have a command in MWorks that directly calls the “setVolume” method, and a separate command that directly calls the “dispense” method.

This is now implemented, but in a different way than I proposed initially.

Starting in tonight’s nightly build, you’ll be able to upload new rate and/or volume settings to the pump without dispensing by assigning to the output variable before you invoke start_device_io (or, equivalently, after you invoke stop_device_io). In other words, you can change the onboard settings at any time, but actual infusion or withdrawal will happen only when the pump has been started. With this change, it probably makes sense to start and stop the pump each trial, so that you can change settings between trials without dispensing. (Note that start_device_io and stop_device_io don’t change any pump-side state; they just set a flag inside MWorks.)

I think this approach is simpler and less confusing than adding a new “volume” parameter, as the existing “variable” parameter already sets the volume.

As I said, this change will be in tonight’s nightly build.

Cheers,
Chris