NXTMMX Daisy Chaining

[gloomyandy]

I don't think there is a problem with the current snapshot, but you do need to do a little more work. You need to replace the command files in the bin directory as well as copying over the lib files (which is what I said in the other post). Have you tried doing this?

Andy

[icemadsen]

You do not need to switch the port between modes to allow access to analogue and i2c data. However many sensors use the digital lines as well as the analogue line so you have to check this on a case by case basis. You will probably be Ok mixing touch and i2c, but you may need to take care with the order that you create the devices...

Andy

Could you specify which order would be the optimal one - instanciate the Touch sensor before or after the MUX's?

[icemadsen]

The touch sensor doesn't use the digital pins, only Gnd and Analog.

We are also using two HiTechnic Touch Sensor Multiplexers (http://www.hitechnic.com/cgi-bin/commerce.cgi?preadd=action&key=NTX1060) - do you know if they also do not use the digital line, so we could f.x attach one to the end of the MUX's?

[mattallen37]

That should be fine. I haven't used one of those, but I have heard it is just a resistor network, so it would just be like an analog sensor. I am quite sure it doesn't use the digital pins for anything.

[icemadsen]

I don't think there is a problem with the current snapshot, but you do need to do a little more work. You need to replace the command files in the bin directory as well as copying over the lib files (which is what I said in the other post). Have you tried doing this?

Andy

I have renamed my release folder to "LeJOS_NXJ.rel" and exported the entire snapshot directory and renamed it to "LeJOS_NXJ" such that everything is replaced with the snapshot version and this gives the aforementioned nxjflash failure

[icemadsen]

That should be fine. I haven't used one of those, but I have heard it is just a resistor network, so it would just be like an analog sensor. I am quite sure it doesn't use the digital pins for anything.

OK, i will also try attaching that to the MUX's, which could also solve our problem with daisy-chaining more than 2 MUX's since we could use two MUX's on one port and one MUX with an Touch sensor MUX attached on another port, which gives us the required two ports free for the Color sensors - this would be the optimal solution! Thanks for your suggestions and response!

[gloomyandy]

Can't be 100% sure as I'm not in a position to check the code at the moment. My best guess would be to create the touch sensor first then the i2c sensor... Should be easy to test though... The touch Mux should also be Ok but only if the pass through is truly a pass through as the sensor code depends on reading different voltages to identify the various touch sensors. If the Mux messes around at all (or adds any extra resistance into the analogue path) you may have problems...

Matt I know the touch sensor only uses analogue and ground, that's why I said it will probably be ok...

If you are still having problems with the snapshot please tell us exactly what you have tried and what OS etc. you are using...

Andy

[mattallen37]

...which could also solve our problem with daisy-chaining more than 2 MUX's...!

Well, that was the idea.

@Andy, I was confirming that. It isn't just probably that the touch sensor doesn't use anything but the Gnd and analog pins, so it shouldn't just probably be okay. What I wasn't sure about, is if the FW reads the analog values even when you are using the port for I2C communication (In NXC, the answer is no).

I believe that the NXTMMX is straight through. I can't think of any reason it would bother with the analog signal.

[icemadsen]

Can't be 100% sure as I'm not in a position to check the code at the moment. My best guess would be to create the touch sensor first then the i2c sensor... Should be easy to test though... The touch Mux should also be Ok but only if the pass through is truly a pass through as the sensor code depends on reading different voltages to identify the various touch sensors. If the Mux messes around at all (or adds any extra resistance into the analogue path) you may have problems...

This should be where the firmware with disabled pull-ups should come in handy, right? Or has I misunderstand the purpose of the pull-ups?

If you are still having problems with the snapshot please tell us exactly what you have tried and what OS etc. you are using...

Andy

On a Windows 7 64bit, with 32bit Java and a fully working LeJOS 0.8.5 release version I've just done the following:
1. Renamed my release folder "LeJOS NXJ" to "LeJOS NXJ.rel" in "Program Files (x86)"
2. Exported the snapshot folder from SVN revision 4254 into "Program Files (x86)"
3. Renamed the snapshot folder to "LeJOS NXJ" in "Program Files (x86)"
4. Executing nxjflash, which fails with the NXTCommException

Using nxjc and nxj seems to be working just fine, so it is just the nxjflashing part that I have problems with.

[skoehler]

4. Executing nxjflash, which fails with the NXTCommException

I'm almost sure, the output is a bit more verbose than that. Please post the complete output of nxjflash.

Update: found a bug, working on a fix.

[gloomyandy]

Hi,
Can you post the details of the exception. Also try copying the jfantom.dll to your leJOS bin directory and see if that helps (you may want to try both the version that is in the snapshot and the old 0.8.5 versions)...

Andy

[icemadsen]

Hi,
Can you post the details of the exception. Also try copying the jfantom.dll to your leJOS bin directory and see if that helps (you may want to try both the version that is in the snapshot and the old 0.8.5 versions)...

Andy

The output is:

Code: Select all

C:\Users\icemadsen>nxjflash
Building firmware image.
VM file: C:\Program Files (x86)\leJOS NXJ\bin\lejos_nxt_rom.bin
Menu file: C:\Program Files (x86)\leJOS NXJ\bin\StartUpText.bin
VM size: 55472 bytes.
Menu size: 44124 bytes.
Total image size 99676/100352 bytes.
Locating device in firmware update mode.
lejos.pc.comm.NXTCommException: Cannot load a comm driver
        at lejos.pc.comm.NXTSamba.search(NXTSamba.java:139)
        at lejos.pc.tools.NXJFlashUpdate.openSambaDevice(NXJFlashUpdate.java:176)
        at lejos.pc.tools.NXJFlash.openDevice(NXJFlash.java:59)
        at lejos.pc.tools.NXJFlash.run(NXJFlash.java:147)
        at lejos.pc.tools.NXJFlash.main(NXJFlash.java:189)

But when I copied jfantom.dll into the leJOS bin directory the output became:

Code: Select all

C:\Users\icemadsen>nxjflash
Building firmware image.
VM file: C:\Program Files (x86)\leJOS NXJ\bin\lejos_nxt_rom.bin
Menu file: C:\Program Files (x86)\leJOS NXJ\bin\StartUpText.bin
VM size: 55472 bytes.
Menu size: 44124 bytes.
Total image size 99676/100352 bytes.
Locating device in firmware update mode.
No devices in firmware update mode were found.
Searching for other NXT devices.
No NXT found. Please check that the device is turned on and connected.

Since the exception did go away, it turns out to be working, but I currently do not have a NXT here with me, so I will try tonight and test all your other suggestions also.

[skoehler]

Update: found a bug, working on a fix.

I could not find any serious problem.
Please update your snapshot to the one I just committed to SVN. Remove the DLL from the bin folder and try running nxjflash again. It should display a better error message that is explaining what's going on.

Update: I tried using 64bit Windows 7 and a 32bit JRE. nxjflash works just fine with the new snapshot.

[icemadsen]

I was able to flash the NXT with the snapshot version, so I did a lot of testing tonight with the new version and the MUX's.

The result is that the I2C implementation in the snapshot version works flawlessly! I was able to daisy chain 3 MotorMUX's and 1 TouchSensorMUX on one SensorPort, which is perfect. I did not change the firmware on the MUX's, so I conclude that the I2C implementation in the release version is causing all of our problems, unfortunately

Since the TouchSensorMUX was able to work on the MotorMUX, we can conclude that the MUX sends straight through, which i also confirmed by succesfully had a LightSensor and a TouchSensor working through the MotorMUX.

However, since this project has all its code based on the release version, we can not use the snapshot version without rewriting most of the code. We are heavily using the setSpeed and setPower in the Motor class, but in the snapshot version, this is moved into two separate Motor classes (NXTMotor and NXTRegulatedMotor). Is there a way of implementing the setPower in the NXTRegulatedMotor class?
Also, do you know how reliable the snapshot version is - is it close to be done and classified as 0.9.0 or is there still missing important features?

Andy: How difficult will it be to add the I2C fixes into the current release version? We could really use this, so we would of course also be willing to pay for it!

[gloomyandy]

Hi,
Can you explain why you need both setPower and setSpeed for the same motor? How are you using them?

It is relatively easy to mix the two motor classes if you need to. Simply create an instance of both use the NXTRegulatedMotor class when you need to use setSpeed, then when you want to use setPower simply call suspendRegulation and start using setPower to control the motor. If you need to use the regulated version again then any call to a method in that class that causes motor movement will enable the regulator again...

At a push you could probably re-create the old motor class by sub-classing NXTRegultedMotor and adding a setPower method that first disables the regulator and then sets the power on the port...


There is no way to move the i2c code back to 0.8.5 without a lot of work, so I don't think that is going to happen, sorry...

Andy