More problems with btmon

[mikeform]

btmon seems it will be a great helper to using my GEM. However, like others, I am having a problem getting things to work. Like others, I am probably doing something wrong.

I have the GEM set up and can see Real Time Data using the JAVA based GreenEye Monitor Setup program, v2.4. The TCP Server button is selected using Port 80. The IP address of the computer is 192.168.1.58 using Port 5000. I can connect and see Real Time Data. The GEM currently uses DCHP and has an IP address of 192.168.1.151.

When I try and run btmon.py with:

btmon.py --device-type=gem --ip --ip-mode=client --ip-host=192.168.1.58 --ip-port=5000 --print
I get an error message " [Errno 10061] No connection can be made because the target machine actively refused it."

No other combination of ip-mode or ip-host address seems to work and changing the GEM to client does not allow the GreenEye Monitor Setup program to connect.

I am confused how things should be set up using the GreenEye Monitor Setup program, v2.4? Is there something missing in the btmon.py command line or elsewhere?

Any help and guidance would be appreciated since I have been stuck with this for a few days. I have Python 2.7 installed on a machine running 64 bit Windows 7.

Thanks.

Mike

[mwall]

is GreenEye Monitor Setup running when you try to connect with btmon? if GreenEyeMonitorSetup is connected to the GEM, btmon will not be able to connect to it.

[ben]

I have the GEM set up and can see Real Time Data using the JAVA based GreenEye Monitor Setup program, v2.4. The TCP Server button is selected using Port 80.

The IP address of the computer is 192.168.1.58 using Port 5000. I can connect and see Real Time Data.

The GEM currently uses DCHP and has an IP address of 192.168.1.151.

btmon.py --device-type=gem --ip --ip-mode=client --ip-host=192.168.1.58 --ip-port=5000 --print
I get an error message " [Errno 10061] No connection can be made because the target machine actively refused it."

Hey Mike,

It looks like there might be an issue with how you're trying to run it.

btmon.py --device-type=gem --ip --ip-mode=client --ip-host=192.168.1.58 --ip-port=5000 --print

If you're running in client mode, the IP-host should be set to the GEMs IP address, it looks like its set to your Computers IP address based on the information above.

If it's an Ethernet GEM, you also want to make sure your GEM is set to a static IP address, and you're using the port specified by the static IP address in the EtherX configuration.

If you're using TCP/IP Server in the GEM Setup Program with Port 80, the command you want to use is likely (might be off in syntax):

btmon.py --device-type=gem --ip --ip-mode=server --ip-port=80 --print

Ben

[mwall]

good eye, ben.

just to clarify the client/server modes for anyone using btmon: the --ip-mode option specifies the mode of btmon, not the mode of the GEM/wiznet.

1) GEM is in server mode
- IP address of GEM is 192.168.X.Y
- GEM is listening on port 5000
- btmon should be run in client mode like this:

Code: Select all

btmon.py --device-type=gem --ip --ip-mode=client --ip-host=192.168.X.Y --ip-port=5000

2) GEM is in client mode
- server address in the GEM configuration should be the IP address of the computer on which btmon is running
- port in the GEM configuration should be arbitrary port number over 1000, say 6000
- btmon should be run in server mode like this:

Code: Select all

btmon.py --device-type=gem --ip --ip-mode=server --ip-port 6000

which mode you choose depends on your network topology, among other things. for example, if the GEM is on one side of a firewall and the computer running btmon is on the other side of the firewall, you probably need to run the GEM in client mode and specify a port that will pass through the firewall.

in most cases the GEM should be in server mode and btmon should be in client mode.

of course this applies only for TCP/IP connections to the GEM - serial connections are direct.

one final caveat: when btmon is in client mode it can either accept real-time packets from the GEM (GEM must be in real-time mode) or it can poll for data (GEM must *not* be in real-time mode). the polling mode is useful if there are multiple computers that need to communicate with a single GEM. in most cases btmon should be in blocking mode (accepting real-time packets from the GEM).

[mikeform]

Thank you both for your quick replies.

I was running GreenEye Setup Monitor, so I will now close that. I am sure that that was part of my problem. Now just a couple more questions.

I set the GEM in SERVER mode with the EtherX configurator and gave it a static "Local IP" address and port. It now seems to work as expected with the btmon switches set for "client", and the IP address and port of the GEM.

I am somewhat confused what the "Server IP" and port are used for in the EtherX. What goes there? Also, why does the EtherX always show "Not Connected"? Does that mean something?

On the data that gets printed out, all of the temperature readings (with no probes installed) are 255.50000. Shouldn't they read as 0?

Also, I notice that some channels read some low value, e.g. 1W, even though nothing is running. Others seem to show 0W correctly. Is there some way to "zero out" the channels so that they read correctly?

Again, thanks for your help.

Mike

[mwall]

On the data that gets printed out, all of the temperature readings (with no probes installed) are 255.50000. Shouldn't they read as 0?

that is due to a change in the gem firmware as of 1.61.

btmon 3.0.6 has a small change to treat 255.5 as zero. technically it should be 'unknown', but the 3.0.x releases of btmon do not explicitly support the notion of unknown values.

you can download the beta 3 release of btmon 3.0.6 here:

http://lancet.mit.edu/mwall/projects/po ... .0.6-b3.py

btmon 3.0.6 also includes better handling of flaky networks and communications. for example, if the wifi drops out then comes back, btmon 3.0.6 will re-establish the connection. 3.0.5 and earlier would timeout then die.

[mwall]

<dns issues have been fixed>

[mikeform]

Thanks. I got to the page with no problems. I will give it a try. I assume that the switches, etc. are the same. Are you at MIT in Cambridge or elsewhere?

Assuming I get this working, next on the agenda is the OW-Server.

Mike