The Software drives me crazy

[Pixopax]

To be honest: As a software developer I must say: This Software is a real piece of crap.
Sorry for the hard words, but it is chaotic, unstable and has so much errors, that I stopped counting them. Every error leads to a hard crash, which is insane.
I cannot understand how someone here is able to place a board with it!

I tried the official version, which does not place my components reliable, also crashes very often. It lacks Error handling almost completely, I could hardly find anything like a descent error handling. ALso, the needed Buttons are somewhere on the window, cameras are not visible at work, switching cams is not working reliable etc. etc.

The rmod4-version is a bit more stable, except that it also randomly crashes, sometimes when I try to jog an axis, sometimes when I select a value from the tape orientation.
Select a part and select "place it", boom, restart please. Here no error handling too. Restart camers? Crash, unhandled exception. Go to next Component...unhandles exception. Wow, really, that is not something you should get to users.

Buttons have wrong hint texts, there is almost no documentation, everything is trial and error.
What also really really sucks is tinyGs reset policy, as soon as you hit a switch, it is game over, restart everything. That is not how cnc machines are supposed to work! I built 4 cnc mills and a cnc lathe, and no, I know what I am talking about.
Also, the software is not able to recover from a tinyg reset, sometimes it starts moving after a reconnect, which I can only stop via a new reset. Sometimes, jogging does not work after reconnect. Sometimes it just starts moving from itself.
I deeply regret that I started this project, really. I don't think this is a machine which is usable for someone who really wants to place parts. For playing around, yes, but not for real work.

I guess I need start my own software, as this seems to be a deadlock, 4 different versions, and all made on the fly, without proper rules or docs. Uff...

[ali]

I was in same situtation as you, I have on old PC laying around, and the software was crashing for multiple reasons, it got me crazy to a point where i was going to put the machine on a corner and forget about it, the reset button was getting crazy, the precision, any time I take the Z up by error. but one day I tested it on a friend PC, and the software was crashing less. Now I bought a new PC (I am mac user, i find myself using more and more PC software), and anyway what I would suggest is work on your crashes one by one, you will understand more why they are crashing and you will reach a point where the crashes and the quality is much better. the software is not good, still needs a lot of improvement people are giving their time to help, this is an open source project.

So just a feedback people are using the lite placer for production you can also do the same, you will need to be more patient and resolve the problems one by one.

[Pixopax]

I am currently sitting on the rmod4-software in Visual Studio.
The software crash when reloading the cameras is fixed already...

But you are right, I will need a lot of patience, as seeing the videos and the website, I thought it would at least allow to place my parts, but that the software is in an early alpha stadium should be mentioned on the store website, before one orders a kit. If I knew that the software is so buggy, I would not have bought the kit, as I do not have much time to sit around and try how to use the software without crashing it.

[dc37]

I am actively working on the machine; if you would like to do some GitHub development I would be very willing to help you work on it!

Recently I tried to place about 370 parts on a board - the result was very .. involved human interaction to get the parts placed. If we get more people working on the software issues one by one and have a schedule set, the software will become more usable.

[assasinsareus]

To be honest: As a software developer I must say: This Software is a real piece of crap.
Sorry for the hard words, but it is chaotic, unstable and has so much errors, that I stopped counting them. Every error leads to a hard crash, which is insane.
I cannot understand how someone here is able to place a board with it!

As a fellow software developer the software needs work but it also has a lot of really cool features already built in.

I have managed to assemble many PCBs now using the default software release and though it does sometimes have it's wobbles mid-job it's very easy to pick up the pieces and carry on from where you left off. Obviously not ideal but workable.

One of the leading causes for concern is Windows itself. Running Windows on a Mac and your really asking for issues. My advice to Juku would be to abandon VS for the POS it is and use another language, maybe QT and then we can use it without needing a Windoom machine.

Seeing as this kit is affordable in a world where PnP machines are truly extortionate is a big hint. The machine itself is great so there has to be some give somewhere. From dealing with Chinese laser cutter machines the software is generally far worse in terms of stability and lack of documentation. My work is currently looking at a refurbed production PnP and it's 20K. More like 100K for a new one.

What also really really sucks is tinyGs reset policy, as soon as you hit a switch, it is game over, restart everything.

I agree this is very frustrating. Maybe the tinyG firmware could be customized so it doesn't do this. To be fair the TinyG uses a ATXMEGA and from my experience with them getting them to do anything is a feat in itself. ATMEGA = no problem, ATXMEGA = major headaches all over the shop.

Juku is very approachable so if you have a concern then let him know and I am sure he will add it to the list.
I can understand your frustrations.

[Pixopax]

The machine itself is very good, a bit slow, but a superb manual, easy to build, and well-designed.

The software is the problem. I could not manage to place even 0805 good enough. Many calibration sessions did not work, it always missed the spot.
The rmod4-version did this precise, even 0402 went exactly. Besides of this both versions have their big errors, yesterday I spent 6 hours (!) trying to build a single board with 10 resistors all in the same direction without errors.
Did not work. The official version did not manage to place the parts where they belong, I had a deviation of ca. 1 mm to all directions. Rmod does that exact. So that is surely a software problem.

Rmod has some other severe errors, ranging from missing the strips from halting in the middle of placement with an "error". Also missing parts and a chaotic list mangement in the parts section, sometimes they are marked as placed, if you want to mark them as placed it unmarks them.
I even had it moving to a strip, got the first part and then moved over the other parts without moving Z down, after reaching the end of the strip it gave out an error.
That was a strip that it previously used without a problem! That are moments where I want to throw the whole stuff in a container.
It also moves to the wrong ways on strips, 15 times it goes down and right to the next part on a -Y strip, and on the 16th try it suddenly moves up and left, exact in the wrong direction, somewhere in the software the strip settings are mangled.

I will give it a try the next 2 weekend days, and try to figure out where the strip direction error is. That is currently my main concern as it destroys all tries to place a complete board.
If it then still is unusable it moves to the basement. Maybe in a year the software has evolved so that I can use it.

Some of the problems are maybe due to the use of this terrible visual studio. I come from Rad studio, which is lightyears ahead in terms of usablility.

[mawa]

... One of the leading causes for concern is Windows itself. Running Windows on a Mac and your really asking for issues. My advice to Juku would be to abandon VS for the POS it is and use another language, maybe QT and then we can use it without needing a Windoom machine.

As a professional software developer using windows since 3.1 and VS for more than a decade I must disagree this statement.

It is not Windows as an OS or VS & C# as the development tool, it is the code design and the code itself that needs rework.

To be honest Juha did a good try but his software architecture, his UI and the resulting code are far from perfect and contain many design flaws.

Rezas rework was half-hearted because he left many of the architectural shortcomings as they are, but he added many cool features in videoprocessing that work surprisingly good.

Yes, you need some courage to refactor the whole piece of work.

I am in the progress of doing so, because I encounter many of the problems reported in this forum and I need a somewhat stable machine to assemble my boards.

But I underestimated the consequences of ripping the whole thing apart and reassembling the single pieces. It takes a lot of more time than I first thought.

mrandt has delivered a whole bunch of good ideas for a simpler UI and I adapted some of them.

I still have some problems with the camera initialisation and am discontent about some hardware related problems like e.g. the Z-axis jamming with an activated limit switch after placing a part with probing. But all can be solved.

I will of course publish my version with the refactored code when I feel it is mature enough. When? I honestly don't know.

All in all I would like to encourage Juha to continue his work. Without his kit we would have no low cost alternative.

[WayOutWest]

What also really really sucks is tinyGs reset policy, as soon as you hit a switch, it is game over, restart everything. That is not how cnc machines are supposed to work! I built 4 cnc mills and a cnc lathe, and no, I know what I am talking about.

I agree 100%. But when I brought this up, people on this forum kept telling me that I don't understand CNC or something like that.

You will find many more bugs in the TinyG software. They had to make a lot of compromises to cram a G-code interpreter into an AVR. In particular the flow control (the serial I/O buffer management and backpressure) is a complete unfixable trainwreck.

I guess I need start my own software

It's not that hard, that's what I did. But I bought the Liteplacer intending to code my own software from scratch before it even arrived, so perhaps the "stock" software was not such a disappointment for me.

Check out the FireSight vision library from FirePick, it'll handle all the hard vision stuff -- or at least get you off to a good start.

One of the leading causes for concern is Windows itself. Running Windows on a Mac and your really asking for issues. My advice to Juku would be to abandon VS for the POS it is and use another language.

I suggested that and was informed that because I think so I must be unprofessional.

What also really really sucks is tinyGs reset policy, as soon as you hit a switch, it is game over, restart everything.

I agree this is very frustrating. Maybe the tinyG firmware could be customized so it doesn't do this.

I attempted this... the short story is that it isn't easy to do it in a way that still prevents the machine from damaging itself.

The TinyG knows how to slam on the brakes quickly in response to a limit switch being hit, but this will cause it to lose positional accuracy, so you'd have to reset (or at least re-home) anyways.

One of the compromises they had to make in order to cram a G-code interpreter into such a tiny machine is that it's very deeply ingrained with certain assumptions about events and queue management. Interrupting the execution sequence in response to a limit switch, and then carefully decelerating the machine as quickly as possible while maintaining positional accuracy, would be a very major architectural change.

Probably the only way to get what you want without having to totally rewrite the TinyG's firmware is to have two sets of limit switches on every axis, one farther out than the other. When the first switch is hit the firmware can use some semi-reliable kludgey hack to try to bring the machine gently to a halt, but this will probably only work 95% of the time. You need the outer limit switches (which will still force a reset) for the remaining 5% so the machine doesn't break itself.

I still have some problems with the camera initialisation and am discontent about some hardware related problems like e.g. the Z-axis jamming with an activated limit switch after placing a part with probing.

You have to issue a SECOND probe (G38.2) command in the opposite direction, away from the switch that you just hit.

This is a TinyG quirk/feature/bug.

I hacked the firmware to "back off" the limit switch after a G38.2 probe, just like the homing sequence does, but the fix only works with my daisy-chained-limit-switches patch which most people can't use (you have to rewire the machine). If you want the patch anyways let me know.

[WayOutWest]

.

[WayOutWest]

.