Your comments
Hi Alistair,
Hopefully the pinout was the problem and the new adapter fixes it.
Check out this topic for clarification on the pinout:
http://community.openice.info/topic/730165-philips-rj45-port-wiring/http://community.openice.info/topic/730165-philips-rj45-port-wiring/
Other community members have had issues with Philips pinout before. If for some reason the standard pinout doesn't work, people have had success with the MP5 pinout:
For the MP70/MX800, you need (DB9 -> RJ45):
2 ->5
3 ->7
5-> 4
For the MP5, you need (DB9 -> RJ45):
2 ->7
3 ->5
5-> 4
Let me know if you fix your issue. Thanks,
Jeff
Hopefully the pinout was the problem and the new adapter fixes it.
Check out this topic for clarification on the pinout:
http://community.openice.info/topic/730165-philips-rj45-port-wiring/http://community.openice.info/topic/730165-philips-rj45-port-wiring/
Other community members have had issues with Philips pinout before. If for some reason the standard pinout doesn't work, people have had success with the MP5 pinout:
For the MP70/MX800, you need (DB9 -> RJ45):
2 ->5
3 ->7
5-> 4
For the MP5, you need (DB9 -> RJ45):
2 ->7
3 ->5
5-> 4
Let me know if you fix your issue. Thanks,
Jeff
Hi Jeremy,
Nice work! Keep us posted on your progress. If you find any errors/bugs in your work with the Intellivue driver code, please consider filing a pull request to the project.
Thanks,
Jeff
Nice work! Keep us posted on your progress. If you find any errors/bugs in your work with the Intellivue driver code, please consider filing a pull request to the project.
Thanks,
Jeff
The beaglebone is a standard linux computer running Debian. The default user is “debian”; the default password is “debian”. You can access the terminal in a variety of ways; the easiest is plugging in a USB keyboard and a monitor (there’s a mini-HDMI port on the beaglebone). Alternatively if you feel comfortable with SSH, you can access the terminal at debian@192.168.13.2 through the Micro-USB port on the beaglebone. USB networking is enabled by default and separate from Ethernet networking so you can use one to change the other.
The official documentation for Debian networking configuration is here: https://wiki.debian.org/NetworkConfiguration#Configuring_the_interface_manually
The network setup interfaces configuration file is located at "/etc/network/interfaces”.
With your preferred text editor, change the block in the file /etc/network/interfaces from:
The official documentation for Debian networking configuration is here: https://wiki.debian.org/NetworkConfiguration#Configuring_the_interface_manually
The network setup interfaces configuration file is located at "/etc/network/interfaces”.
With your preferred text editor, change the block in the file /etc/network/interfaces from:
auto eth0to:
allow-hotplug eth0
iface eth0 inet dhcp
auto eth0Obviously use your preferred IP addresses. After you’ve saved your changes to the config file, restart the beaglebone with `sudo reboot`.
iface eth0 inet static
address 192.0.2.7
netmask 255.255.255.0
gateway 192.0.2.254
Hi Brad,
I'm not sure if there is a single piece of information to recommend, but I've found PrismTech CTO Angelo Corsaro's Slideshare account to be a great source of information.
For example:
http://www.slideshare.net/Angelo.Corsaro/vortex-tutorial-part-i
http://www.slideshare.net/Angelo.Corsaro/vortex-tutorial-part-ii
WRT to one of your previous questions about late joiners, tutorial part 2 specifically covers the durability quality of service policy starting on slide 29.
Another useful resource is Jeff Plourde's webinar OpenICE Technical Introduction. It covers high level DDS information and how Jeff applied them to the development on the platform.
Other than that, the API docs are the most comprehensive reference. https://community.rti.com/rti-doc/510/ndds.5.1.0/doc/html/api_java/examples.html
Thanks,
Jeff Peterson
I'm not sure if there is a single piece of information to recommend, but I've found PrismTech CTO Angelo Corsaro's Slideshare account to be a great source of information.
For example:
http://www.slideshare.net/Angelo.Corsaro/vortex-tutorial-part-i
http://www.slideshare.net/Angelo.Corsaro/vortex-tutorial-part-ii
WRT to one of your previous questions about late joiners, tutorial part 2 specifically covers the durability quality of service policy starting on slide 29.
Another useful resource is Jeff Plourde's webinar OpenICE Technical Introduction. It covers high level DDS information and how Jeff applied them to the development on the platform.
Other than that, the API docs are the most comprehensive reference. https://community.rti.com/rti-doc/510/ndds.5.1.0/doc/html/api_java/examples.html
Thanks,
Jeff Peterson
The IDL is found in our git repo - the IDL is found under /master/data-types/x73-idl/src/main/idl/ice/ice.idl.
To generate code for the IDL, we use rtiddsgen. The code generator is documented here.
At the command line, enter:
To generate code for the IDL, we use rtiddsgen. The code generator is documented here.
At the command line, enter:
rtiddsgen -language C -inputIdl /path/to/repo/data-types/x73-idl/src/main/idl/ice/ice.idl
Hey Brad,
This is fantastic work! Thank you for taking the time to track down the solution. Is there a way we can share this fix or workaround with others? You mentioned that your code is adapted from HelloICE.java, can we alter that to avoid this?
Thanks,
Jeff
This is fantastic work! Thank you for taking the time to track down the solution. Is there a way we can share this fix or workaround with others? You mentioned that your code is adapted from HelloICE.java, can we alter that to avoid this?
Thanks,
Jeff
"Without a supervisor" sounds like the "simple setup" here: https://www.openice.info/docs/6_example-setups.html#simple This setup has no BBB, but instead runs both the ICE_Device_Interface (aka Device Adapter) and the OpenICE Supervisor on the same machine. In this setup you would plug the RS232 directly into the computer, no LAN required. Take a look at the sample setups for some inspiration. Essentially you need one instance of ICE_Device_Interface (Device Adapter) connected to the serial port of each device and a Supervisor (or custom app) to subscribe to the devices. The adapters and supervisors are connected by a network, even if it's just the local loopback adapter.
HelloOpenICE https://github.com/mdpnp/hello-openice is sample code for subscribing to the data structures that the Device Adapters (ICE_Device_Interfaces) are publishing the same way the Supervisor functions. The sample code should allow you to quickly write application level software without the immense struggle of writing code for the underlying middleware (DDS).
Feel free to startup a new thread as issue arise. I'm happy to help.
Thanks,
Jeff
HelloOpenICE https://github.com/mdpnp/hello-openice is sample code for subscribing to the data structures that the Device Adapters (ICE_Device_Interfaces) are publishing the same way the Supervisor functions. The sample code should allow you to quickly write application level software without the immense struggle of writing code for the underlying middleware (DDS).
Feel free to startup a new thread as issue arise. I'm happy to help.
Thanks,
Jeff
Hey Brad,
I believe that DeviceIdentity should be shared with late joiners by the DDS layer as part of the discovery process. I think of DDS as a hybrid discovery service and distributed cache. When a subscriber discovers and matches a publisher, it should read the other writer's current state information, including the DeviceIdentity. I'm not an expert with the intricacies of the DDS implementation however so I will confirm this answer and elaborate.
This is where I look for DDS documentation: http://community.rti.com/rti-doc/510/ndds/doc/html/api_c/group__DDSSubscriberExampleModule.html
Thanks,
Jeff
I believe that DeviceIdentity should be shared with late joiners by the DDS layer as part of the discovery process. I think of DDS as a hybrid discovery service and distributed cache. When a subscriber discovers and matches a publisher, it should read the other writer's current state information, including the DeviceIdentity. I'm not an expert with the intricacies of the DDS implementation however so I will confirm this answer and elaborate.
This is where I look for DDS documentation: http://community.rti.com/rti-doc/510/ndds/doc/html/api_c/group__DDSSubscriberExampleModule.html
Thanks,
Jeff
Hi Alistair,
Unfortunately, Oracle removed support for JavaFX on ARM devices. This means that the OpenICE Supervisor will not build or run on the Beaglebone platform anymore. Due to resource constraints (and to the fact we JUST rebuilt the GUI with JavaFX), we have chosen to say that the Supervisor is not compatible with ARM anymore. Although it is foreseeable that someone may want to run both a Device-Adapter and Supervisor on one beaglebone device, we envision a future where the Supervisor apps are doing complex computations that exceed the capabilities of an ARM beaglebone.
If you would like to run the device-adapter and supervisor on one board, I would suggest investigating a small x86 system like the Intel NUC. If running the Supervisor in a centralized location is not a problem, run the Device-Adapter on an ARM device and the Supervisor on a laptop/desktop/server.
Here is a nice link that about sums up the situation: https://www.linkedin.com/pulse/oracle-just-removed-javafx-support-arm-jan-snelders
Thanks,
Jeff
Unfortunately, Oracle removed support for JavaFX on ARM devices. This means that the OpenICE Supervisor will not build or run on the Beaglebone platform anymore. Due to resource constraints (and to the fact we JUST rebuilt the GUI with JavaFX), we have chosen to say that the Supervisor is not compatible with ARM anymore. Although it is foreseeable that someone may want to run both a Device-Adapter and Supervisor on one beaglebone device, we envision a future where the Supervisor apps are doing complex computations that exceed the capabilities of an ARM beaglebone.
If you would like to run the device-adapter and supervisor on one board, I would suggest investigating a small x86 system like the Intel NUC. If running the Supervisor in a centralized location is not a problem, run the Device-Adapter on an ARM device and the Supervisor on a laptop/desktop/server.
Here is a nice link that about sums up the situation: https://www.linkedin.com/pulse/oracle-just-removed-javafx-support-arm-jan-snelders
Thanks,
Jeff
Customer support service by UserEcho