Reprap error – Software freeze at axis is this because of an RXTX mismatch or something else?

Hi,

Hope all are well.

I wonder if it’s possible for some feedback regarding some issues I’m having with my RepRap build – Here’s some background info. Apologies if I’ve gone overboard with the details but I thought it best to provide as much information as possible.

Build – Mendel – Connected through COM1 on the communications port on my Laptop.
Platform – Windows 7 Home Premium – 64 bit
Electronics – Gen 3 (1.2 Motherboard, 2.2 Extruder (linked to Adrian’s Extruder and Stepper Motor) and 3x2.3 Stepper Motor Drivers).
Firmware - I’m unsure of the Firmware version currently on these boards, however they were tested on Windows XP without any problems (courtesy of Przemek Jaworski - thanks). Because they have been tested, I don’t want to change the firmware on either of the boards just yet as it does not seem to be the cause of the problem.
Extruder – Adrian’s Geared Extruder with heater wire and bead thermistor – no external thermocouple board is being used.
RepRap Host Software – I’m using the 64 bit RepRap software (20100719) to connect the software to my Mendel. Files are located in C:\Program Files\Reprap.
Java Version– Java 6 installed from the download ‘JDK-6u25-windows-x64’

Errors
• Host software freeze when clicking on ‘Home’ or when specifying a movement in mm. This is not consistent as sometimes the software freezes when ‘Homing’ and sometimes when an instruction is sent
• Error in temperature readout – remains at ‘000’ although heater wire heats up and thermistor is connected.

Both the Reprap and Java folders are located in the ‘C:\Program Files’ folder.
I have set the Environment Variable path to the JDK bin file (both User and System variables are called ‘Reprap’ and link to the ‘C:\Program Files\Java\jdk1.6.0_25\bin’ folder.

In the example below, before any of the electronics were powered up, the X, Y and Z axis are manually placed into mid-axis positions to allow for homing to be done as this is a point where the error occurs.

I connect the motherboard to my laptop using the USB/TTL cable, power up the stepper motors and extruder board and then run the software. Image of the output is attached.



The host software seems to have loaded correctly as I am able to see the 3 software windows.
The temperature readout at M105 appears to be accurate – I’m not sure of the ‘B:-16’ text at this point.
There is an RXTX mismatch but I have seen other threads where this error is shown but links have suggested it shouldn’t cause any major issues (http://forums.reprap.org/read.php?1,43526,43526,quote=1). If this must be updated, please let me know.

I have followed up the start-up of the software with 1 axis move (X). This has been successful and the axis was stopped by the opto switch which lit green. No software freeze yet.



I then try to check the temperature on the Extruder tab on the host software. I made no changes to the preferences for the extruders so the temperature settings were kept at 190C across all 3. At this point I’m just after a readout of some sort on the Extruder tab (‘Current Temperature’)
I leave the heater on for about 15 seconds, during this time there is no change in the temperature readout on the Host software. The extruder barrel does get very hot – far hotter than the 14C recorded earlier.



At this point I turn off the heater and stop the testing. I believe there should be temperature readings output every 3 seconds but this can’t be seen.

I then go back to homing the remaining the axis as there has been no software freeze.

Y Axis Home – Success
Z Axis Home – This is where it normally goes...and because I’m doing a test, it doesn’t



As this is the case – I send an instruction for the X axis to move 100mm. The x axis does move 100mm and it is at this point, the software freezes.




If I close the cmd box and restart the software without disconnecting the power/motherboard, I get the following error, I’m not sure if this has any relevance.



So, in summary – I can’t get a temperature reading from the host software and the software seems to freeze depending on what axis instrucctions are sent to the machine. Is the cause of either of the errors because of the RXTX mismatch or could it be something else?

If you have experienced any similar issues, please let me know how you managed to get around this.

Thank you all in advance.

Raj

I am having the same problems. Connecting with the arduino software and querying for temperature through the serial monitor returns the temperature fine.

Seems like a 64-bit host problem...

---

---

reprapworld.com
PLA, ABS, PETG multiple colors (3 and 1.75 mm) €16,49 / kg
Megatronics 3.0 €79.99 / Minitronics €37,19

I took a look at the standard 64 bit firmware (20100719) and uploaded this to the motherboard. Before doing so I added

'#define EXTRUDER_COUNT 1' (below #define INCHES_TO_MM 25.4)

and

'#define USE_THERMISTOR' (below '#define MENDEL 1')

to the relevant places in the configuration.h file in the firmware upload.

This stopped the axis from freezing when they were homed and i'm also able to register accurate temperature readings on the Reprap Host software and also RepSnapper without the software freezing.

So, it appears as if the RXTX mismatch was not the cause of the issue.

I still can't print though as i'm having trouble generating G Codes - I'll check the forums and see if anyone has had similar problems.

Raj

Hi Raj, if you like, I can send you a zip file with gcodes I just made via skeinforge... 20mm cube with 2mm walls. I'm extruding 3mm PLA. I was very happy with the result of these skeinforge settings.

Best,
Chris

I used this version (201000719 64 bit) on a Mac OS 10.5.8 with TZ gen 3 remix and I encountered most of the issues you reported but I was able to print with it. I quickly abandoned using the reprap host to generate GCODE and used Skeinforge. But I still used the reprap host (as well as repsnapper) to send the GCODE file to the printer. I encountered problems with the print stalling at random times with either the reprap host or repsnapper. After trying different combinations of reprap host and firmware, I found that a 20101221 nightly release works best with this electronics. It doesn't stall, but it would occasionally pause and then continue after a few seconds. It's still not good when it does that since it leaves a blob, but its better than completely stalling. I'm now changing over to RAMPS electronics.