[Solved] Software disconnects during baking or reflow

[lintilla]

+1 to the "software hangs during bake process" here too. Happens every time.

The software do not say disconnected, but the timer stops.
I just close the program and let the machine run it's cycle.
When led turns blue I can open the software again and it connects just fine.

[lumeffects]

From my experience, the ftdi makes a virtual com port but the application program has to connect to that. If the ftdi is forced to close and reopen the com port, the app is often unaware and will automatically loose the link, even if the com port is reestablished as the same com port number. This is a fundamental usb com port connectivity problem which my company forever had problems with.
Reestablishin a broken serial usb link is achievable but can be tricky and problematic. It's most probably the applications responsibility to detect and reestablish the link.

[Eriond]

I agree that keeping a COM port link can be tricky, and that you have take special care for the disconnect event. With FTDI, there is a second option: to use the D2XX DLL. This gives the programmer more options as it connects directly via the USB stack. Not sure which method the Voltera app uses, but if sudden disconnects are an issue, maybe the D2XX could be a way forward? (hint, hint )

[HBijlsma]

The same / really similar problem here.. So I can confirm the problem
On a windows 10 computer while baking the time remaining stops and the v-one is non-responsive.

At first I thought it maybe was the FTDI driver, because I used an already existing driver installation. After changing the driver to the one on the voltera website the board still performs the same.

Random time stops after 1-5 minutes of baking.
It happens every time, even after system reboots etc.
(Software version v0.6.5)

[HBijlsma]

Giving some experimentation it looks like the printer becomes unresponsive on the moment the heating elements re-engages.

Tried at a 'manual' setting of 160degrees celcius, the printer was cooling from the 200+ degrees of the bake..
After dropping below the setting (160) the printer again becomes unresponsive.

[jazozaya]

Hi @HBijlsma,

On a windows 10 computer while baking the time remaining stops and the v-one is non-responsive.

Can you clarify what you mean by the V-One is non responsive? Do you mean that:

1. The software freezes completely and eventually white screens and crashes?
2. The software remains responsive, but sending more commands like homing the system, or outlining a print do nothing. (The printer does not move)
3. The software remains responsive, but the buttons are not visible and instead display "Please Wait" or similar.

It's worth mentioning that the entire heating profile is loaded onto the printer as soon as you hit bake. The printer will continue baking even if the software crashes or you physically unplug the unit. If the printer stops 1-5 minutes into the bake, it is possible that the serial connection broke, but the printer is still running fine. When a bake cycle finishes and the printer is cooling down, the LED's will flash blue, so you can use these as an indication.

With that said - the printer will reset if you restart the software, this will wipe out the baking profile and you will lose the progress.

We are still looking into the source of this issue, we made some changes to how serial communication is handled last week and are hoping to release the next SW version this week.

---

Jesus Zozaya

[HBijlsma]

The time on the screen freezes...
The program stays responsive, the printer keeps baking (the leds still pulsate and the temperature is good)
Stopping the bake makes the software application crash. (Or any other action which communicates with the printer)

When restarting the program software, it cannot connect to the printer anymore. (keeps searching)
Only a hard-reset (on/off/on) from the printer makes communication possible...

[HBijlsma]

Additional info:
My problem is only for the 'bake' and manual settings..
The reflow -> automatic worked perfectly

[troy]

This may have been fixed in 0.0.7, i.e. "Resolved an invalid function call that would have left the app in a semi-responsive state." Some of the log files I have point to that toward that issue/fix.

@HBijlsma if you submit a support package for this i can read the log file to confirm that it contains the pattern I am expecting (if not then it helps anyway). I know you are already submitting a package for another issue, but please submit again for this one. I think that will make it easier to track the resolution.

For those who already submitted a package, i have likely already scanned your log files.

For everyone, if you still see this in 0.7 please report again, I'll need a new log file too.

Cheers

[HBijlsma]

Just sent the packages (0.6.5 version and 0.7.0 version)

Hope you can make sense of it

The 0.7.0 version seems to have the same problem, but is more robust. (the program doesn't crash afterwards)

[troy]

Thanks @HBijlsma.
I was able to read through the logs last night and again today. There were a couple of odd things in there and I've generated some tickets to follow up on them. I don't have an explanation for the issue yet. In your 0.7 log the printer reports an error saying that it was unable to heat to the target...but i saw another attempt to heat later that worked.

Another set of logs could help rule out (or in) a few things. For example, I saw a FW update, and some errors trying to connect just after that. After ~30s the software is able to connect. Another odd thing is that you were able to start a manual heating job during that 30s period. Not sure how because the start button should have been disabled. If you do this again can keep an eye on the connected/disconnected status in the upper right, knowing what that says would be useful.

ALL: Some logs from others could help. They will help narrow done the common steps needed...or reveal that there's more than one bug here.

Thanks again.

[ka911]

Just a update from me - tried my first print (from macOS) - and it hung about 7 minutes into the bake cycle. Software was still "responsive" but no time updates and no error messages. Pressed STOP - and got spinning wheel and "Please Wait" message and nothing else.

Printer is still baking - but it is a bit of an annoying problem.

MacOS latest
Voltera 0.8.0

[jazozaya]

Hi everybody.

We just rolled out software version 0.10.0.

Please let us now if your heating problems have been resolved or if they keep occurring.

[cborn]

Hi Jesus,

I just updated and ran a reflow cycle, and can confirm the fix works for me in the release as it did in the test version.

Thanks, David

[Knochi]

Hi there,

I ran into similar problems. We have the Voltera Application 0.11.2 installed to a 64-bit Win7 desktop machine.
After some minutes in the baking process the printer gets disconnected, i have the software in the background running.

how can i debug this? is tehre some kind of event logging? i already deactivated the energy saving option for USB, without success.

Thanks in advance
David

[mewertow]

Hi David,

If you're running into consistent disconnect issues, there are a couple steps you can take to debug the issue:

1) Try different power / USB cables
2) Try using the V-One with a different computer / laptop, if you have one available
3) Unplug or turn off other USB devices, as well as other devices on the same circuit as the V-One. We have seen that noisy environments can cause disconnect issues.
4) If all else fails, try using the V-One on a different outlet / circuit, perhaps in another room.

Some disconnect issues are caused by poor connection between the V-One and the computer, but others can be induced by other equipment. Let me know if any of the above suggestions help with the problem.

• Matt

[Knochi]

Hi Matt,

With a Laptop the V-One runs quite well. Must be something with the USB of the Desktop PC.
The USB Interface of the Voltera seems very sensible/unstable. Can we do something on Hardware site? We are an experienced hardware design team and able to modify circuits board on our own.

Thanks in advance
David

[Knochi]

Hi Matt,

update on the USB failures... we tried a different USB Cable (USB2.0 Premium) and it works now on the desktop machine as well.
Maybe you should put better cables to your deliveries.

Cu
David

[jazozaya]

Hi @Knochi,

I'm glad swapping out the cable did the trick.

We are taking your feedback seriously and am currently looking for a better USB cable supplier we can use for our next production run.

Cheers

[cborn]

This can be a real problem. A while back we had a batch which refused to charge the Lithium cells in our meters, and on investigation we found that each of the conductors, data and power, were around 6 Ohms end to end!

Charging a Lithium cell at 4.2V from a 5V USB supply over a total of 12 Ohms (6 Ohms each way) would leave us with <70mA charge current. The device draws around 200mA when running, so if left turned on when plugged in to charge they would be going backwards.

Finding good cables was a matter of looking for something which appeared to have a substantial thickness and then metering test samples. The ones we are using now have <0.2 Ohms per conductor and give us our full 500mA (or 1A depending on model) charge current.