1. Support
  2. OpenICE
  3. Bugs
0
Fixed

IntelliVue MX800 over LAN with Demo Apps

Thomas Drake-Brockman 10 years ago in OpenICE • updated by Andrei Paduraru 8 years ago • 12
Hey,

I've been attempting to connect to our IntelliVue MX800 over LAN with the OpenICE demo apps.

I have established a network connection to the monitor from my laptop successfully, and can ping the device. However, I'm unable to get the device adapter to connect to the monitor over LAN.

I inspected network traffic with Wireshark, and saw no communication at all addressed to the monitor IP that I entered when starting the device adapter.

Thanks,
Thomas
GOOD, I'M SATISFIED
Satisfaction mark
Satisfaction mark by Thomas Drake-Brockman 10 years ago
Thomas Drake-Brockman 10 years ago
I should note that I have confirmed that several CONNECT INDICATION EVENT packets were found in the Wireshark dump from my testing session and that they were sent to the appropriate broadcast address.
Thomas Drake-Brockman 10 years ago
Today I attempted a connection over serial with the same MX800. I received the following error:

Console:
Exception in thread "main" org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'rtConfig' defined in class path resource [DriverContext.xml]: Bean instantiation via factory method failed; nested exception is org.springframework.beans.BeanInstantiationException: Failed to instantiate [org.mdpnp.apps.testapp.RtConfig]: Factory method 'setupDDS' threw exception; nested exception is com.rti.dds.infrastructure.RETCODE_ERROR: error creating entity at org.springframework.beans.factory.support.ConstructorResolver.instantiateUsingFactoryMethod(ConstructorResolver.java:602)
 at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateUsingFactoryMethod(AbstractAutowireCapableBeanFactory.java:1111)
 at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:1006)
 at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:504)
 at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:476)
 at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:302)
 at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
 at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:298)
 at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:193)
 at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:762)
 at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:757)
 at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:480)
 at org.mdpnp.apps.testapp.Configuration.createContext(Configuration.java:147)
 at org.mdpnp.apps.testapp.IceAppsContainer$IceAppsContainerInvoker.execute(IceAppsContainer.java:422)
 at org.mdpnp.apps.testapp.Main.main(Main.java:51)
Caused by: org.springframework.beans.BeanInstantiationException: Failed to instantiate [org.mdpnp.apps.testapp.RtConfig]: Factory method 'setupDDS' threw exception; nested exception is com.rti.dds.infrastructure.RETCODE_ERROR: error creating entity
 at org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:189)
 at org.springframework.beans.factory.support.ConstructorResolver.instantiateUsingFactoryMethod(ConstructorResolver.java:591)
 ... 14 more
Caused by: com.rti.dds.infrastructure.RETCODE_ERROR: error creating entity
 at com.rti.dds.util.Utilities.rethrow(Unknown Source)
 at com.rti.dds.infrastructure.NativeFactoryMixin.create_entityI(Unknown Source)
 at com.rti.dds.domain.DomainParticipantFactoryImpl.create_participant(Unknown Source)
 at org.mdpnp.apps.testapp.RtConfig.setupDDS(RtConfig.java:61)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:606)
 at org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:162)
 ... 15 more

UI:
Disconnected (error initializing RS-232 to UDP purecomm.PortInUseException)
As an asside, I also noticed that the OpenICE supervisor appears to only start when I have an active network connection, is this by design?

Thanks,
Thomas
Started
Jeff Plourde 10 years ago
Hi Thomas,

Thank you for your feedback. Let me try to make sure I understand what has and hasn't worked for you. Also, for my reference, are you using the latest version 0.6.1 of the software?

If I understand you correctly running the OpenICE software on your laptop, specifying the IntellivueEthernet device and your phys. monitor's IP address allowed you to connect successfully?

Also when you say the device adapter has been unable to connect are you referring to a beaglebone device adapter?

Some other useful background information:
Thank you, it is very helpful to know you are seeing CONNECT INDICATION events to the broadcast address because it tells us you've gotten IP networking squared away on the monitor. If you leave the device adapter "address" specified as a blank string it ought to await these beacons and attempt to connect to the first monitor it "hears". We have limited resources so we don't get to regression test this behavior for every release but I'll double-check it in the lab. When you specify an ip endpoint for the connection these beacons are ignored by the device driver.

Currently we are using standards-based DDS middleware along with the standardized RTPS/DDSI wire protocol. The only standardized "platform-specific module" of that wire protocol is based on UDP/IP so an active network stack is indeed required. We are using a community-licensed implementation from RTI that we to-date haven't been able to configure to successfully use the loopback adapter so yes a true active network is currently required. You're not the first person to encounter this problem and we're trying to consider ways to ameliorate it. This is, in fact, the most common source of 'entity creation' errors people see as the DDS library will not successfully initialize when it has no means to communicate with other network nodes.

Also regarding the serial port connection I'm glad that you are also attempting that modality. A common source of PortInUseExceptions stems from the common use of RS-232 connections for consoles in the beaglebone community. So when we buy mini RS-232 capes they are hardwired for ttyO0 and the default debian distribution assigns a getty console to that port. In our images for beaglebone we've disabled that serial port console. In our images we also typically add the default 'debian' use to the dialout group because the /dev/ttyO0 port gets root ownership in the dialout group by default.

I hope with more info we can get you up and running!

Thanks
Jeff Plourde

Thomas Drake-Brockman 10 years ago
Hi Jeff,

So far I'm running all software on my laptop, including the OpenICE Supervisor and a Local Device Adapter. As of yet I have not been able to connect to our Philips MX800 using either LAN or RS232.

When attempting to connect over LAN I was able to confirm that the network was connected between my laptop and the monitor, and that I could see the broadcasted CONNECT INDICATION events.

I had been using version 0.5.0 of the demo-apps, although now that I see that 0.6.1 is available I will move to using that. Further, I will attempt not specifying the monitor IP when initializing the Local Device Adapter, and I'll have to check again the permissions for /dev/ttyUSB0 on my machine.

Thanks,
Thomas
Thomas Drake-Brockman 10 years ago
Hi Jeff,

I've managed to get OpenICE 0.6.1 running on my local machine, after a little fiddling with JDK versions.

I noticed a commit from you in the SourceForge repo suggesting an issue with mislabelling of Philips device adapters. Is this something I need to be looking out for?

Thanks,
Thomas
Thomas Drake-Brockman 10 years ago
Hi Jeff,

I performed further testing on Friday with our MX800, this time using version 0.6.1 of the OpenICE software, and the Oracle JVM 1.8.0_45.

When attempting connection over LAN, as before I have no success. Whilst the monitor sends connection indication events, the OpenICE Device Adapter never seems to attempt to connect. I'm curious as to if this might be related to my computer having more than 1 network adapter. I'm using a crossover cable, with both my laptop and the MX800 with static addresses assigned.

Further, the RS232/MIB connection was also unsuccessful. The OpenICE Device Adapter window showed a 'Connection State' of 'Negotiating' but did not progress further. Is there any known way to test the serial connection to the monitor? I'm slightly suspect I may have made an error in wiring my RJ45 to RS232 adapter, although I followed the manual.

Again, and assistance or direction would be greatly appreciated.
Thomas
Jeff Peterson 10 years ago
Hey Thomas,

As an incremental step in fixing the problems listed above, please download OpenICE v0.6.2. There is a minor bug fix that had major impact on instantiating the Philips LAN device-adapter. After you upgrade, shoot me back a message with what doesn't work still and we'll get you running.

Jeff
Thomas Drake-Brockman 10 years ago
Hey Jeff,

Updated to 0.6.2 and attempted connection over LAN. Worked brilliantly!





I haven't tried serial yet, although I don't really need it for my usecase currently.
I will give it a go next time I'm working with the monitor, because it would be nice to have that work also.

Thanks for all your help.
Thomas
Andrei Paduraru 8 years ago

Hi Thomas,


We are trying to centralize data from MX800 devices for a newborn intensive care unit using RS232 and we are stuck in the same connection state you mentioned above: Negotiating (Requesting Association). Did you manage to get past that phase? I can run a simulated device on the Beaglebone adapter and view the data in the supervisor app, so I know the problem is between the adapter and the MX800, maybe some additional config might be required on the MX800 side. The time we can spend fiddling with the medical device is very limited, we do not have a device on our hands to experiment with, which makes debugging really difficult.


I see you managed to get it working over LAN, we will also try that the next time we have access to the medical device. Is there any additional config required besides setting static IPs and starting the device adapter as IntellivueEthernet?


Any help would be much appreciated.


Thank you,

Andrei

Thomas Drake-Brockman 8 years ago

Hey Andrei. We ended up going with a LAN connections, which worked fine for us. We set the monitor up to use DHCP and had a cheap modem-router to plug the monitor and PC into. Worked fairly reliably.

Andrei Paduraru 8 years ago

Hey Thomas. Thanks for the quick reply! We'll try this setup as well.

Fixed
Jeff Peterson 10 years ago

Customer support service by UserEcho