Re: Go!Temp & java
Stephen Bannasch
I'm copying your message and my reply to the org-conco...@googlegroups.com email list. We can continue the thread there.
I turned off moderation for you so you should be able to post there now. I'm also using a separate email address because I'm sending to the google mail list.
At 11:13 PM +0000 11/19/10, Michael Borcherds wrote:
>Hi,
>
>I think I'm just about there: I've got TestNative.java working in
>Eclipse with the output below.
>
>I don't quite understand why I'm getting an error, I've changed line 87 to this:
> sensor.setType(SensorConfig.QUANTITY_DISTANCE);
>
>but at least I'm getting some real data :)
>
>Also, have you got any idea how I can get the Go!Temp working? It's
>got vid 0x08f7 pid 0x0002
I'm not sure about this. I don't have a goTemp with me and before I left work today I couldn't find one.
Can you share the console output when you try running TestNative with the GoTemp attached.
>thanks,
>
>Mike
>
>Loading sensor device: org.concord.sensor.nativelib.NativeVernierSensorDevice
>Wrong Sensor Attached: This data collection requires a QUANTITY_DISTANCE sensor.
>However a Go! Motion is attached
I'm not sure why you are getting this error.
The console message is being printed on line 373 in SensorDataProducerImpl
This is being called because the test on line 259 actualConfig.isValid() is returning false.
This is a boolean in ExperimentConfig.java.
Do you have more than one Vernier device attached?
I see the following comments there:
* If the set of sensors attached does not match the requested sensors then
* this should be false.
This starts here in the C code: sensor-native/target/classes/c/GoLinkSensorDevice.c
78:#define SENSOR_ID_GO_MOTION 69
And below in your console output it reports the same: attached sensor number: 69
>started device
>1 0.396772
>1 0.399483
>1 0.39679
>1 0.396344
>1 0.395966
>1 0.39317
>1 0.393222
>SensDev_open
> successfully called GoIO_Init
>open_go
> device address:
>\\?\hid#vid_08f7&pid_0004#6&2e1091f9&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}
> goHandle: 195299952
> state->sensorID: 0
> Unlocked the device 2 times
>sensor measurement period: 0.100000
>configure_sensor
> attached sensor number: 69
> sensor long name: Go! Motion
> sensor short name: Cyclops
> sensor activeCalPage: 0
> sensor units: )
> sensor current: 0
>SensDev_configure
>close_go
>open_go
> device address:
>\\?\hid#vid_08f7&pid_0004#6&2e1091f9&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}
> goHandle: 195631688
> state->sensorID: 69
> Unlocked the device 2 times
> go-link opened
> goio period: 0.100000
>configure_sensor
> attached sensor number: 69
> requested sensor id: 13
> requested sensor requiredMax: 1.#QNAN0
> requested sensor requiredMax isnan: 1
> sensor long name: Go! Motion
> sensor short name: Cyclops
> sensor activeCalPage: 0
> sensor units: )
> sensor current: 0
>SensDev_start
> goHandle 195631688
> started measurements
>SensDev_stop
>SensDev_stop
>Closing device
>close_go
When I changed line 87 to QUANTITY_DISTANCE I get the following console output:
I plugged a GoMotion in and goit the following console output running TestNative
Loading sensor device: org.concord.sensor.nativelib.NativeVernierSensorDevice
ExperimentConfig
deviceName Unknown device type
This response isn't correct and seems to be because the switch statement on line 262 in sensor-native/src/c/GoLinkSensorDevice.cdoesn't test for a GoMotion -- but since it works this seems to be just annoying. But note it's returning "invalid" ...
dataReadPeriod 0.1
exactPeriod true
invalid true
invalidReason null
SensorConfig
name Position
type 13
typeConstant QUANTITY_DISTANCE
port 0
portName ?'
stepSize 0.01
confirmed true
unit m
started device
1 1.50957
1 1.509998
1 1.506242
1 1.499537
1 1.499863
1 1.510136
1 1.50662
SensDev_open
successfully called GoIO_Init
open_go
device address: 0xfa140000
goHandle: 0x102203030
state->sensorID: 69
Unlocked the device 1 times
sensor measurement period: 0.100000
configure_sensor
attached sensor number: 69
sensor long name: Position
sensor short name: x
sensor activeCalPage: 0
sensor units: (m)
sensor current: 0
SensDev_configure
close_go
open_go
device address: 0xfa140000
goHandle: 0x100615a30
state->sensorID: 69
Unlocked the device 1 times
go-link opened
setting measurement period to: 0.100000
goio period: 0.100000
configure_sensor
attached sensor number: 69
requested sensor id: 13
requested sensor requiredMax: nan
requested sensor requiredMax isnan: 1
requested sensor stepSize: 0.100000
requested sensor stepSize isnan: 0
sensor long name: Position
sensor short name: x
sensor activeCalPage: 0
sensor units: (m)
sensor current: 0
SensDev_start
goHandle 0x100615a30
started measurements
SensDev_stop
SensDev_stop
Closing device
close_go
Stephen Bannasch
>
>I plugged a GoMotion in and goit the following console output running TestNative
>
> Loading sensor device: org.concord.sensor.nativelib.NativeVernierSensorDevice
> ExperimentConfig
> deviceName Unknown device type
>
>This response isn't correct and seems to be because the switch statement on line 262 in sensor-native/src/c/GoLinkSensorDevice.cdoesn't test for a GoMotion -- but since it works this seems to be just annoying. But note it's returning "invalid"...
I fixed this problem with this change:
$ git diff src/c/GoLinkSensorDevice.c
diff --git a/src/c/GoLinkSensorDevice.c b/src/c/GoLinkSensorDevice.c
index c4db173..da04217 100644
--- a/src/c/GoLinkSensorDevice.c
+++ b/src/c/GoLinkSensorDevice.c
@@ -266,6 +266,9 @@ int SensDev_getCurrentConfig(
case GoDeviceType_GoTemp:
sprintf(expConfig->deviceName,"GoTempSensorDevice");
break;
+ case GoDeviceType_GoMotion:
+ sprintf(expConfig->deviceName,"GoMotionSensorDevice");
+ break;
default:
sprintf(expConfig->deviceName, "Unknown device type");
}
I can easily rebuild the Mac sensor-native build but I have not been able to successfully build the Windows version.
Michael Borcherds
Here's the trace when (just) a Go!Temp is plugged in :
Loading sensor device: org.concord.sensor.nativelib.NativeVernierSensorDevice
Sensor Interface Not Found: Vernier Go! Device could not be found.
no error message yet
Exception in thread "main" java.lang.NullPointerException
at org.concord.sensor.nativelib.TestNative.main(TestNative.java:73)
SensDev_open
successfully called GoIO_Init
Closing device
thanks,
Mike
On 20 November 2010 05:21, Stephen Bannasch
> --
> You received this message because you are subscribed to the Google
> Groups "org-concord-sensor" group.
> To post to this group, send email to org-conco...@googlegroups.com
> To unsubscribe from this group, send email to
> org-concord-sen...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/org-concord-sensor?hl=en?hl=en
> Google Code project for org-concord-sensor: http://code.google.com/p/org-concord-sensor/
Stephen Bannasch
>Thanks - what tools are needed to build it on Windows?
>
>Here's the trace when (just) a Go!Temp is plugged in :
>
>Loading sensor device: org.concord.sensor.nativelib.NativeVernierSensorDevice
>Sensor Interface Not Found: Vernier Go! Device could not be found.
>no error message yet
>Exception in thread "main" java.lang.NullPointerException
> at org.concord.sensor.nativelib.TestNative.main(TestNative.java:73)
>SensDev_open
> successfully called GoIO_Init
>Closing device
Mike,
Can you put a breakpoint at line 114 in JavaDeviceFactory and tell me the value for the local variable: id when a GoTemp isconnected?
Michael Borcherds
On 20 November 2010 16:22, Stephen Bannasch
<stephen....@deanbrook.org> wrote:
> At 9:49 AM +0000 11/20/10, Michael Borcherds wrote:
>>Thanks - what tools are needed to build it on Windows?
>>
>>Here's the trace when (just) a Go!Temp is plugged in :
>>
>>Loading sensor device: org.concord.sensor.nativelib.NativeVernierSensorDevice
>>Sensor Interface Not Found: Vernier Go! Device could not be found.
>>no error message yet
>>Exception in thread "main" java.lang.NullPointerException
>> at org.concord.sensor.nativelib.TestNative.main(TestNative.java:73)
>>SensDev_open
>> successfully called GoIO_Init
>>Closing device
>
> Mike,
>
> Can you put a breakpoint at line 114 in JavaDeviceFactory and tell me the value for the local variable: id when a GoTemp isconnected?
>
Stephen Bannasch
>id=10
That's the same id as my standard GoLink.
See if you step through that method to see if the anything else shows up.
I have to head out now to play with my friend Roo who has built this: http://roopod.com/roopod-is-street-legal/
... be back much later today.
Michael Borcherds
int result = NativeBridge.SensDev_isAttached(deviceHandle);
is returning 0
On 20 November 2010 18:16, Stephen Bannasch
> --
> You received this message because you are subscribed to the Google
> Groups "org-concord-sensor" group.
> To post to this group, send email to org-conco...@googlegroups.com
> To unsubscribe from this group, send email to
> org-concord-sen...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/org-concord-sensor?hl=en?hl=en
> Google Code project for org-concord-sensor: http://code.google.com/p/org-concord-sensor/
--
Michael Borcherds
Lead Developer
International GeoGebra Institute
www.geogebra.org
Stephen Bannasch
> int result = NativeBridge.SensDev_isAttached(deviceHandle);
>
>is returning 0
I think that means it's a problem in the C code.
I'm going to see if I can find a GoTemp today and replicate the problem.
You could also try running: http://rites-investigations.concord.org/investigations/107.jnlp
Go to a the Simple Temperature Graph page in the Authorable Components Activity and let me know whether that works or does not work with the GoTemp.
If it doesn't work I'd like to see a copy of the relevant part of the Java console and any details reported by an error dialog in the app if one appears.
Michael Borcherds
on another computer.
The problem was that I had a lib-usb driver installed as well.
thanks,
Mike
On 22 November 2010 14:16, Stephen Bannasch
<stephen....@deanbrook.org> wrote:
>>Line 154 of NativeVernierSensorDevice
>> int result = NativeBridge.SensDev_isAttached(deviceHandle);
>>
>>is returning 0
>
> I think that means it's a problem in the C code.
>
> I'm going to see if I can find a GoTemp today and replicate the problem.
>
> You could also try running: http://rites-investigations.concord.org/investigations/107.jnlp
>
> Go to a the Simple Temperature Graph page in the Authorable Components Activity and let me know whether that works or does not work with the GoTemp.
>
> If it doesn't work I'd like to see a copy of the relevant part of the Java console and any details reported by an error dialog in the app if one appears.
>
Stephen Bannasch
>Sorry, just done what I should have done in the first place and tested
>on another computer.
>
>The problem was that I had a lib-usb driver installed as well.
Great that it is working!
I'm working on documenting the process for integrating new drivers. I'm hoping to get an Arduino driver created and integrated.
What installs and uses the 'lib-usb' driver that was causing the conflict?
Do you think this might happen to other developers ... or even worse users in the field?
Can you think of a way for us to have detected the driver conflict, or reported a more informative error message?
Michael Borcherds
http://www.geogebra.org/webstart/test-usb/ggbtest-usb.jnlp
Note that the points may appear off-screen, and it sometimes crashes
when you stop logging.
If you right-click on the buttons and go to Object Properties ->
Scripting -> JavaScript you can see how it works (a JavaScript
function is triggered when a USB event comes in)
You can be confident that no user will have a lib-usb driver installed
(you have to run an exe to make your own driver). I have no idea how
to test for it though. I can send you the driver if you want.
(libusb is a library for low-level USB stuff which is what I was
playing with until I found you :)
cheers,
Mike
On 22 November 2010 19:48, Stephen Bannasch
<stephen....@deanbrook.org> wrote:
> At 7:00 PM +0000 11/22/10, Michael Borcherds wrote:
>>Sorry, just done what I should have done in the first place and tested
>>on another computer.
>>
>>The problem was that I had a lib-usb driver installed as well.
>
> Great that it is working!
>
> I'm working on documenting the process for integrating new drivers. I'm hoping to get an Arduino driver created and integrated.
>
> What installs and uses the 'lib-usb' driver that was causing the conflict?
>
> Do you think this might happen to other developers ... or even worse users in the field?
>
> Can you think of a way for us to have detected the driver conflict, or reported a more informative error message?
>
Stephen Bannasch
>I've just got a webstart version of GeoGebra working with USB support :)
>http://www.geogebra.org/webstart/test-usb/ggbtest-usb.jnlp
>
>Note that the points may appear off-screen, and it sometimes crashes
>when you stop logging.
>
>If you right-click on the buttons and go to Object Properties ->
>Scripting -> JavaScript you can see how it works (a JavaScript
>function is triggered when a USB event comes in)
>
>You can be confident that no user will have a lib-usb driver installed
>(you have to run an exe to make your own driver). I have no idea how
>to test for it though. I can send you the driver if you want.
>(libusb is a library for low-level USB stuff which is what I was
>playing with until I found you :)
>
>cheers,
That's great. Is your source checked into a svn branch?
On Windows 7 it came up, I plugged in a GoLink with fast-response temperature probe, clicked Start Logging and data appeared inthe table on the left but nothing was graphed.
See screencast: http://screencast.com/t/XCA4Gr2Ng
Wasn't clear whether the data was temperature but it did start and stop when logging was started and stopped.
No errors in Java console.
Getting this error on Mac OS X 10.6.5
com.sun.deploy.net.FailedDownloadException: Unable to load resource: http://www.geogebra.org/webstart/test-usb/jogl-natives-macosx-universal.jar
at com.sun.deploy.net.DownloadEngine.actionDownload(DownloadEngine.java:1372)
at com.sun.deploy.net.DownloadEngine.getCacheEntry(DownloadEngine.java:1525)
at com.sun.deploy.net.DownloadEngine.getCacheEntry(DownloadEngine.java:1503)
at com.sun.deploy.net.DownloadEngine.getResourceCacheEntry(DownloadEngine.java:1609)
at com.sun.deploy.net.DownloadEngine.getResourceCacheEntry(DownloadEngine.java:1534)
at com.sun.deploy.net.DownloadEngine.getResource(DownloadEngine.java:217)
at com.sun.javaws.LaunchDownload$DownloadTask.call(LaunchDownload.java:1979)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:680)
Michael Borcherds
(I think :)
<resources os="Mac OS X" arch="ppc">
<nativelib href = "vernier_ccsd-mac-static.jar" />
</resources>
<resources os="Mac OS X" arch="i386">
<nativelib href = "vernier_ccsd-macintel-static.jar" />
</resources>
<resources os="Mac OS X" arch="x86_64">
<nativelib href = "vernier_ccsd-macintel-static.jar" />
</resources>
If you right-click (with nothing selected) and select "Show all
objects" the points will be on screen (or you can use the mouse wheel,
or zoom tool etc)
Code is in SVN trunk here:
http://www.geogebra.org/trac/wiki/SetUp
geogebra.usb.USBLogger
geogebra.plugins.ScriptManager
cheers,
Mike
On 23 November 2010 03:03, Stephen Bannasch
<stephen....@deanbrook.org> wrote:
> At 7:58 PM +0000 11/22/10, Michael Borcherds wrote:
>>I've just got a webstart version of GeoGebra working with USB support :)
>>http://www.geogebra.org/webstart/test-usb/ggbtest-usb.jnlp
>>
>>Note that the points may appear off-screen, and it sometimes crashes
>>when you stop logging.
>>
>>If you right-click on the buttons and go to Object Properties ->
>>Scripting -> JavaScript you can see how it works (a JavaScript
>>function is triggered when a USB event comes in)
>>
>>You can be confident that no user will have a lib-usb driver installed
>>(you have to run an exe to make your own driver). I have no idea how
>>to test for it though. I can send you the driver if you want.
>>(libusb is a library for low-level USB stuff which is what I was
>>playing with until I found you :)
>>
>>cheers,
>
> That's great. Is your source checked into a svn branch?
>
> On Windows 7 it came up, I plugged in a GoLink with fast-response temperature probe, clicked Start Logging and data appeared inthe table on the left but nothing was graphed.
>
> See screencast: http://screencast.com/t/XCA4Gr2Ng
>
> Wasn't clear whether the data was temperature but it did start and stop when logging was started and stopped.
>
> No errors in Java console.
>
>
> Getting this error on Mac OS X 10.6.5
>
> com.sun.deploy.net.FailedDownloadException: Unable to load resource: http://www.geogebra.org/webstart/test-usb/jogl-natives-macosx-universal.jar
> at com.sun.deploy.net.DownloadEngine.actionDownload(DownloadEngine.java:1372)
> at com.sun.deploy.net.DownloadEngine.getCacheEntry(DownloadEngine.java:1525)
> at com.sun.deploy.net.DownloadEngine.getCacheEntry(DownloadEngine.java:1503)
> at com.sun.deploy.net.DownloadEngine.getResourceCacheEntry(DownloadEngine.java:1609)
> at com.sun.deploy.net.DownloadEngine.getResourceCacheEntry(DownloadEngine.java:1534)
> at com.sun.deploy.net.DownloadEngine.getResource(DownloadEngine.java:217)
> at com.sun.javaws.LaunchDownload$DownloadTask.call(LaunchDownload.java:1979)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:680)
>
Stephen Bannasch
Please try on your Mac now. I've put the correct lines in the jnlp now
(I think :)
<resources os="Mac OS X" arch="ppc">
<nativelib href = "vernier_ccsd-mac-static.jar" />
</resources>
<resources os="Mac OS X" arch="i386">
<nativelib href = "vernier_ccsd-macintel-static.jar" />
</resources>
<resources os="Mac OS X" arch="x86_64">
<nativelib href = "vernier_ccsd-macintel-static.jar" />
</resources>
If you right-click (with nothing selected) and select "Show all
objects" the points will be on screen (or you can use the mouse wheel,
or zoom tool etc)
Stephen Bannasch
It would be great if you wrote up a blog post at some point describing how you integrated our work into Geogebra. I'd love to
reference it for other developers. I know the NetLOGO developers might be very interested.
Werner Keil
Stephen Bannasch
Hi Werner,
Yes, the Java Sensor library is alive.
Here's what I wrote a couple of days to Paulo Blikstein who wants to extend this work to a new interface.
>At 12:27 PM -0700 10/19/11, Blikstein, Paulo wrote:
>>Hi Stephen,
>>
>>I hope this email finds you well.
>>We're trying to make the GoGo Board work in HTML5 and I was wondering if you have any tips of good sources of information for my students not to reinvent the wheel...
>
>Yes.
>
>You can use our work at CC as a template.
>
>The most useful thing is to write a native driver for the GoGo board that uses the built-in HID USBdriver. This means thatfolkswho want to use it over the web will NOT need any sys admin permission to access the GoGo from a browser. That means itis MUCHeasier to use in schools.
>
>Take a look at: http://jnlp.dev.concord.org/goio-temperature-graph.html
>
>If you plug in a Vernier GoIO temperature sensor into your USB port that page will graph data from it.
>
>I tested this on Mac OS 10.4, 10.5, and 10.6 PPC, i386 and x86_64, Windows XP and Windows7.
>
>And in the following browsers: Safari, Chrome, and FireFox on the Mac, Safari, Chrome FireFox, IE8,IE9, and Opera on Windows.
>
>I use a signed Java applet which loads an OS and architecture specific driver from Vernier written in C++.
>
>It was a big pain getting the signed applet with the specific native driver it loads automatically to work properly in all these case AND actually cache as much of the downloaded Jar and Nar files as possible.
>
>A key point here is that the applet has no user-visible UI. It is just used to facilitate communication between the graphing program in JavaScript and the native C++ Vernier driver that then communicates via the USB HID interface to the Vernier GoIO device.
>
>The Vernier GoIO SKD is open source so you can take a look at it to see how you might write your own driver. I have a mirror ofthe GoIO SDK here: https://github.com/concord-consortium/goio_sdk
>
>The Vernier SDK is also available from them here:
>
>http://www.vernier.com/downloads/software-development-kits/go-sdk/
>
>The web app is here: https://github.com/stepheneb/lightweight-sensor-graphs
>
>The readme should tell you how to get it working.
>
>The repo for the lightweight-sensor-graphs native libraries as nar files and a number of jar files that are built from other Java projects.
>
>The Java code in the lightweight-sensor-graphs repo currently uses JNI to communicate with the Vernier driver. We have newer code that uses JNA instead. JNA-based code is **MUCH** easier to modify and maintain.
>
>I am working on this code now so I'd like to hold off describing the build system and dependencies for the older code used in the current lightweight-sensor-graphs repo because this part of the system should be much more sane in a few days.