needle height calibration always crashes software

[WayOutWest]

Hi,

I have the machine built and all limit switches tested. When I initiate the "needle height calibration" the needle correctly descends until the limit switch triggers, then backs off, then prompts me to "Jog Z axis until the needle just barely touches the PCB then click Next".

At this point I have about a 5-second window to either move the head in the Z-axis direction by 10mm or more, or do nothing.

If I attempt any other action (i.e. move less than 10mm, move along other axis), my command is ignored and the liteplacer crashes.

If I wait 5 seconds doing nothing, it crashes.

If I move the head in the Z-axis direction by 10mm or 100mm it does obey my command, but then it crashes as well.

Basically no matter what, it crashes like this:

Code: Select all

########## System.IO.IOException: The I/O operation has been aborted because of either a thread exit or an application request.

Below is the crash log.

Please tell me how to manually input the "Z0 to PCB" value; the calibration mechanism is not working and I need to enter this number manually.

Thanks,

[WayOutWest]

Code: Select all

"sr":{"posz":37.850,"feed":100.00,"vel":100.00}}
==> {"gc":"G0 Z28.136"}
{"sr":{"posz":37.525}}
{"sr":{"posz":37.201}}
{"sr":{"posz":36.956,"vel":0.09}}
{"sr":{"feed":0.00,"vel":0.00,"coor":1,"dist":0,"stat":3}}
ReadyEvent stat
{"qr":32,"qi":1,"qo":1}
{"r":{},"f":[1,0,20,100]}
{"sr":{"posz":36.956,"vel":0.55,"stat":5}}
{"qr":31,"qi":1,"qo":0}
{"sr":{"posz":34.115,"vel":2026.62}}
{"sr":{"posz":28.412,"vel":641.00}}
{"sr":{"posz":28.136,"vel":0.00,"stat":3}}
ReadyEvent stat
{"qr":32,"qi":0,"qo":1}
==> {"zsx":2}
{"r":{"zsx":2},"f":[1,0,10,2814]}
ReadyEvent r
==> {"zsn":2}
{"r":{"zsn":2},"f":[1,0,10,2906]}
ReadyEvent r
==> {"zsn":3}
{"r":{"zsn":3},"f":[1,0,10,3720]}
ReadyEvent r
G1 Z28.236
==> {"gc":"G1 Z28.236"}
{"r":{},"f":[1,142,20,2162]}
########## System.IO.IOException: The I/O operation has been aborted because of either a thread exit or an application request.

   at System.IO.Ports.InternalResources.WinIOError(Int32 errorCode, String str)
   at System.IO.Ports.SerialStream.EndRead(IAsyncResult asyncResult)
   at System.IO.Ports.SerialStream.Read(Byte[] array, Int32 offset, Int32 count, Int32 timeout)
   at System.IO.Ports.SerialStream.Read(Byte[] array, Int32 offset, Int32 count)
   at System.IO.Ports.SerialPort.Read(Byte[] buffer, Int32 offset, Int32 count)
   at LitePlacer.SerialComm.DataReceived(Object sender, SerialDataReceivedEventArgs e)
########## System.InvalidOperationException: The port is closed.
   at System.IO.Ports.SerialPort.Read(Byte[] buffer, Int32 offset, Int32 count)
   at LitePlacer.SerialComm.DataReceived(Object sender, SerialDataReceivedEventArgs e)

[JuKu]

I need to look into this deeper, but I'm not in my office right now. I haven't seen this before, but I have a scenario candidate: There is an issue in the software related to recovering problems. From your earlier issues, there is a loose thread competing for TinyG Access, and this gives it a window to mess things up. Please try the following: Reset TInyG and reboot your computer or ensure with task manager that there are no LitePlacer relater processes running. If the issue is still there with a clean start, send me steps to replicate.

As noted, this is of course not the expected behaviour, no have I seen that before. The log you sent is fine, I don't see any issues there. I hope a reboot and clean start solves this, as otherwise this might turn out to be difficult to solve. As noted, I haven't seen this and right now, I don't even have any other ideas than the above.

[WayOutWest]

The log you sent is fine, I don't see any issues there.

Hrm, really, this message is fine?

Code: Select all

########## System.IO.IOException: The I/O operation has been aborted because of either a thread exit or an application request.

Unfortunately rebooting did not help; I've still got persistent problems with commands to the z-axis motor crashing the TinyG.

I understand that this is a kit project and a lot of tweaking and tuning is necessary, but I have to say that the error reporting from the TinyG is a major issue here. It doesn't seem to report any error messages; instead it just crashes itself! This is really not good; without diagnostic information from the TinyG indicating why it is unhappy it becomes exponentially harder to troubleshoot problems.

I'm no longer sure if the issue here is that the TinyG is failing to report errors, or if the host software is misinterpreting the error reports and simply crashing itself before it can receive the error report. I'm going to start programming the TinyG directly through the serial port as a first step towards replacing the TinyG entirely -- something I have always intended to do but did not plan on attempting this early on! I had hoped to get the placer fully up and running using the "stock" software before trying to rewrite it, but if I can't get usable diagnostics out of the stock software and/or the TinyG then one (or both) of those must be replaced... diagnostic information is pretty basic and critical, there's just no way around not having it.

[JuKu]

The log you sent is fine, I don't see any issues there.

Hrm, really, this message is fine?

Code: Select all

########## System.IO.IOException: The I/O operation has been aborted because of either a thread exit or an application request.

Unfortunately rebooting did not help; I've still got persistent problems with commands to the z-axis motor crashing the TinyG.

Fine until the error, I meant. The log clip didn't show any reason for this. The error is from LitePlacer software, not from TinyG, at least not directly. Even if it might originally start from TinyG, it should be handled more graciously.

Are the TinyG LEDs blinking? If so, you have a noise issue with your limit switches. But I assume this is not the issue, so
could you please do this: Reset TinyG, wait for the blinking to stop, start LitePlacer software, home it (or at least z axis), try height calibration (fail) and copy the whole log window content (cntrl-a selects all) to a text file and email it to me?

[mrandt]

as a first step towards replacing the TinyG entirely

Adam, why are you so unhappy with TinyG and which controller do you suggest to use instead?

I must admit that I like the TinyG:

I have been working with a lot of other controllers and firmware in the past, mostly in the field of 3D printing and small CNC mills. Frankly, most of them totally sucked. Poorly written code, terrible error handling, questionable electronic design and similar problems - worst of all were the ones in factory made professional" 3D printers... Ever tried to debug Marlin or Repetier?

Compared to that, TinyG just worked like a charm

Best thing about TinyG firmware is their algorithm to compute and control acceleration and deceleration in a way which makes movements very smooth and significantly reduces wear and tear while improving positioning accuracy at high speeds. The only other affordable controller I know that does something similar is Smoothieboard, which I did not have a chance to try out yet.

I wished Synthetos had a exposed a few more digital and analogue pins of the MCU for special purposes, but other than that the hardware is nicely designed and produced.

I think the JSON protocol is a huge improvement over normal G-codes, especially as it allow for continues feedbacks and bi-directional event reporting. From my experience, the error handling is not bad. TinyG never just "crashed" on me, there are situations in which it goes into an exception state though - indicated by a red blinking light - which is OK for presumably unrecoverable errors.

Your specific problem here seems to be in LitePlacer host software and not TinyG. LitePlacer software still has some bugs. I also agree that exception handling and TinyG communication needs to be improved in the host software - but I can accept that LitePlacer software is at an early stage and expect that things like these will improve over time. With the help of some other user's contributions, big advancements have already been made within the last months.

If you are brave enough to try a beta, download and install Reza's mod (commonly referred to as LitePlacer Ver2) from the link in this post:
http://liteplacer.com/phpBB/viewtopic.p ... rt=30#p606

Calibration functions have much improved in this version compared to Juha's original software. Needle height, PCB thickness and backoff calibration are now three distinct routines which IMHO yield better results and are easier to use.

Make sure to set your machine size (max machine) on "calibration & locations" tab after first start - and calibrate needle height first, then backoff and PCB thickness (order of buttons is not intuitive yet).

You can have original LitePlacer and Ver2 installed simultaneously, so you can switch back and forth. However, I think that long term the Ver2 will be the one to use and Juha as already said he was to maintain it going forward.

[WayOutWest]

as a first step towards replacing the TinyG entirely

Your specific problem here seems to be in LitePlacer host software and not TinyG .... exception handling and TinyG communication needs to be improved in the host software

That is probably the case, although I am by default disinclined to blame Juha for things because he made such a great machine

As I have been reading more about the TinyG I've been pretty impressed so far, so I am leaning more and more towards thinking that the "TinyG unreliability" I have been frustrated by is in fact unreliability in the LiteplacerHostSoftware<->TinyG communication, and could be the fault of the LiteplacerHostSoftware.

The only two gripes I currently have that I can definitely attribute to the TinyG are both very minor:

1. It uses that stupid FTDI chip, they are really unreliable -- like nearly all USB-to-serial adapters, which work "just barely well enough" if you don't push too hard or ask them to do anything out of the ordinary. They already have an AVR chip on there, why not speak native USB using a library like LUFA? Or at the very least do the serial-port emulation in software on the AVR. I think this may be partly to blame for the unreliability; there are just so many extra layers of software and drivers adding more and more opportunities for things to go wrong. In fact I think Juha even got burned by this at one point, he said that the TinyG will "seem to work" with Windows' default USB-serial drivers, but will fail in strange ways, and the fix is to install the FTDI drivers. I say just do away with the whole serial port pretension in the first place.

2. It isn't open source. I understand the guy who makes the TinyG needs to eat. But I also know it's inevitable that I will one day become unacceptably limited by this, so every hour I spend learning about the TinyG is an hour of effort that will some day need to be thrown away.

The most likely case for #2 is that I can foresee needing to get precise timing relationships between "motion completed" and some other action. Having to wait for the TinyG to notify the host software, so the host software can then perform the action is problematic -- at best it will cripple the machine's speed; at best it may mess up a build due to late reactions. Here's one example of a feature in this category.

I've heard it's possible to add modules to the TinyG, but that you have to use AVR studio... ugh/yuck. I have never used it or even installed it, for me avr-gcc "just works".

[JuKu]

> I am by default disinclined to blame Juha for things because he made such a great machine

Thank you. Also, thank you for your trust, but I'm not that perfect. My software can be improved; so much so, that thereza wrote his own (see rmod thread in the software section)!

TinyG software is open source, the hardware design is not, but the schematics are published. Its license is at least as free as mine.

[Covert]

SO I seem to have a related issue.

After over an hour trying to get it to work again a reload of defaults ($defa=1) and set up the software again. I don't think it is software related since I can take the other laptop and plug it in and I get the same error.

Seems to error when it attempts a Z movement (picking up a part)

Code: Select all

Optical homing OK.
PickUpPart_m(), tape id: 4v7B
GotoNextPart_m(), tape id: 4v7B
Part 0  Source Location = (82.99,36.19,-90.27)
CNC_XYZA: 84.97,32.68,,
GoToThing(Circle), FindTolerance: 1.5, MoveTolerance: 0.1
GetClosestCircle(1.5)
--> round 0, offset= (0.05,0.00,0.00) dist/tol = 0.05 of 1.5
== NEEDLE ==pos (83.04,36.19,-90.27) + offset (102.52,22.97,0.00) - wobble (-0.26,-0.31,0.00) = (185.82,59.47,-90.27)
CNC_XYZA: 185.82,59.47,,-90.27
**  X185.671099193015 Y59.4676754511183 A-110.265520802203
currentAMachine -110.266 + da 20.0004791977969 = A -90.2655208022031 (%360=-90.2655208022031)
**  A-90.2655208022031
########## System.IO.IOException: The I/O operation has been aborted because of either a thread exit or an application request.

[Covert]

The solution to my problem was to disable slack calibration. That fixed the crash/halt of the TinyG. I edited "A" slack compensation out of the source and left X/Y slack compensation so I could still use that feature. I'll re-visit the bug once I have a better understanding of the code. I'm like a bull in a China shop with the code atm.