100Hz pulse on SS2 Vacuum TinyG firmware?

[Roman Valls]

Hello Mark,

After following your excellent blog posts on vacuum sensing on:

https://makr.zone/tinyg-new-g-code-commands-for-openpnp-use/577/

https://makr.zone/openpnp-advanced-vacuum-sensing-part-on-part-off-detect/421/

I flashed the ADC-enabling-on-pin-SS2 TinyG firmware you have on the first blogpost but for some reason me and my colleagues cannot understand, the TinyG board generates a 100Hz pulse on SS2 when it's supposed to just read ADC values?

That's before even connecting a vacuum sensor and independently of connecting or not OpenPnP. In fact when connecting OpenPnP (green power button on the OpenPnP UI), going to the GCodeDriverAsync console and sending some M105 commands, we get those readings (I insist, without anything else connected):

> M105

ok T: 1244

tinyg [mm] ok>

> M105

ok T: 1434

tinyg [mm] ok>

> M105

ok T: 3886

tinyg [mm] ok>

> M105

ok T: 1248

tinyg [mm] ok>

So the peak of 3886, keeps repeating on some of the M105... we think that matching those 100Hz pulses being generated on the SS2 (mapped to PB3 pin on the xmega).

Is this something you've observed before? Can it be that the TinyG.7z released on your site has seen some changes or that there's some altered TinyG setting ($$) I should be aware of and modify accordingly?

[mark maker]

Hi Roman,

You're probably the first that really tests this. @Michael Schober said he would test it here...

https://groups.google.com/g/openpnp/c/SpnIfjEoiuI/m/LMgSRJ3uAQAJ

... but if I'm not mistaken, he never actually reported back. I'm frankly not even sure if I tested it electronically myself. It is well possible that I made a mistake in the setup, I really just took the code of Thereza.

At the time I was assuming Micheal would test it immediately. Then I probably just assumed I would hear back if it didn't work. Unfortunately, that TinyG ADC discussion thread then got completely hijacked after that.

Having said that...

> I insist, without anything else connected

Leaving the SS2 pin open will likely give random ADC reads. The 100Hz could easily be a harmonic interference from the 50Hz mains, and if you probed it with long oscilloscope with multimegaohm impedance, this is even very likely.

Do you have a potentiometer (10 kOhm or similar) that you could connect across the 3.3V and then go from the tap to SS2?

You should also connect a cap in parallel, as I documented.

             ______
+3.3V o-----[______]---o GND
           10k ^       |
               |   1uF |
               o---||--o
               |
              SS2

Please stay on it! 😁

_Mark

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/b8e69cf7-e68e-4a0d-a711-e219ba37eadfn%40googlegroups.com.

[Roman Valls]

I soldered the 1uF cap underneath the board, you cannot see it in the
photo, but it's there from the beginning, as documented by you ;)

I'll try the 10k resistor and/or pot next Tuesday... if you can think
of any other reason, please do tell in advance since I'm there only
once a week. We revised your TinyG code and the adc_init() & co and it
seems sound, btw... but perhaps there's something somewhere else on
the firmware that could be generating that 100Hz PWM-looking-like
pulse?

> You received this message because you are subscribed to a topic in the Google Groups "OpenPnP" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/openpnp/0tcJh1ygayk/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to openpnp+u...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/1a8aced1-f559-32d7-1301-82b6fe35fb96%40makr.zone.

[mark maker]

> but perhaps there's something somewhere else on the firmware that could be generating that 100Hz PWM-looking-like pulse?

Hmmm... naturally, the SS1 pin would normally be a SPI select line, perhaps I should have done something to relinquish SPI control? Though I always thought these are just plain software controlled IOs on these old 8bit MCUs, i.e. not actually controlled by some built-in SPI hardware.

The only other thing that I can think of, is that I made a mistake when building the later firmware, i.e. the one that also solves the "spindle control plus Z-probe" issue that must be solved for the Liteplacer. Look for "UPDATE 2022-04-24" here:

https://makr.zone/tinyg-new-g-code-commands-for-openpnp-use/577/

Perhaps I zipped the wrong hex? Although the date seems right. The hex is baked right into the corresponding code changes, including ADC (I checked):

https://github.com/synthetos/TinyG/pull/276

To be sure, please try this hex:

https://raw.githubusercontent.com/markmaker/TinyG/a61772d00c3432b2dddfb587e24d6a87ab0f8e50/firmware/tinyg/Debug/tinyg.hex

I  have the quirky AVR build environment on my old computer, i.e. can't just spin a new version readily...

Any chance you could do that yourself? If would enable you to actually experiment with the code, if you're only there once in a week:

https://github.com/synthetos/TinyG/wiki/Project-Setup-For-Atmel-Studio6.2

_Mark

[Ian Arkver]

I'm guessing here, but I see in your patch you disable the xio_open for SPI2 but I don't see anything akin to an xio call for the ADC. Does the Mega need some pinmuxing to enable the analog channels? What's the default pinmuxing?

You added a call to adc_init but that seems concerned only with the ADC block itself.

[disclaimer, I haven't looked at any datasheets here and don't have the hardware myself so may be barking up the wrong tree entirely.]

Regards,
Ian

[mark maker]

Its a bit embarrassing, but I really just took the code from Thereza (seems to be deleted now), which reportedly worked. To be honest: while it all made sense, I did not really know what I was doing in terms of all the Atmega specifics.

The code was a bit cleaned up, taking only what is needed from the ATmega SDK, and controlled with different G-code. But unless I made a mistake, all the original stuff should be there. I was very careful then.

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/1c29ac89-90cf-4033-838f-a06bb7d2f53an%40googlegroups.com.

[Ian Arkver]

I took a quick look at the code. It's hard to follow exactly what is used where due to the levels of indirection.

It might be worth removing SS2 from this define though...

#define SPI_OUTBITS_bm  (SPI_MOSI_bm | SPI_SCK_bm | SPI_SS1_bm | SPI_SS2_bm)

which is at line 81 of firmware/tinyg/xio/xio_spi.h. It seems to be used for both SPI instances.
But I can't really be sure it will help and I can't test it.

Otherwise the ports default to inputs so the ADC should work if single ended sampling on channel 3 (port B3) is set up right. xboot doesn't seem to use this pin either.

Regards,
Ian

[mark maker]

Thanks for your help, Ian, that seems a valid suspicion.

Like I said I cannot currently look into that, maybe Roman can.

But I will keep it in the back of my mind.

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/41d351bb-0478-4190-bf84-483c7e72ef06n%40googlegroups.com.

[Roman Valls]

Ian, thanks for taking the time to take a look at the code and give your best guess, here's the change you proposed:

https://github.com/markmaker/TinyG/pull/2/commits/cc12baafc7cd042f1764dbc3cb24394691d5c877

Unfortunately, I just flashed the resulting tiny.g hex, but it doesn't work, we are still seeing the 100Hz signal on the scope :/ We'll now take a deeper look at the TinyG code and try to figure out what's going on. Any further guesses/hints are more than welcome!

@Mark: If I'm the first trying this vacuum sensing method, what are you using yourself for your LitePlacer machine nowadays? :-S

[mark maker]

> we are still seeing the 100Hz signal on the scope :/

Is that on a real oscilloscope? (i.e. not just one of these "signal monitors")

Is it a strong rectangular signal, definitely driven by the MCU? Or could it be interference?

Have you ever just tied the SS2 to GND and +3V3 respectively, using a 10k resistor, and then used M105 to see if you can see the difference?

> @Mark: If I'm the first trying this vacuum sensing method, what are you using yourself for your LitePlacer machine nowadays? :-S

I replaced the controller:

https://makr.zone/choosing-a-motion-controller-the-panucatt-azteeg-x5-gt-32bit/455/

Using this for sensing:

https://makr.zone/vacuum-sensor/192/

But that was at a time when OpenPnP still strongly advised against using the TinyG. But a lot of Liteplacer users still kept using it, then hit the obvious problems when they wanted to do advanced stuff, so I finally added the missing G-code commands:

https://makr.zone/tinyg-new-g-code-commands-for-openpnp-use/577/

Quite some work invested there, so please do not give up yet, I'd like very much for it to work. 😁

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/3d9753c8-3954-4691-ba7c-307fae89bf5cn%40googlegroups.com.

[mark maker]

> Have you ever just tied the SS2 to GND and +3V3 respectively, using a 10k resistor, and then used M105 to see if you can see the difference?

Now that I wrote that down, a recollection manifests, that I actually did that when I developed the ADC addition. I'm not 100% positive whether I did it or just thought about it. Actually, the image in my head is about recklessly used a paperclip to short SS2 to GND and +3V3 respectively (my controller test bed is actually in my office, no electronic tools or parts laying around 😁).

A transformer PSU uses a rectifier, which creates a 100Hz half-waves signal with typical capacitor inrush pulses:

https://electronics.stackexchange.com/a/441961

If it is a phase cutting PSU, it is the same issue:

https://en.wikipedia.org/wiki/Phase-fired_controller

If you leave the SS2 port floating, and attach the high impedance (typically 10MOhm) leads of the scope to it, it is almost guaranteed to pick those 100Hz up.

In my shop I had fluorescent tube overhead lights, they were all over my scope signals. I had to replace them with LEDs. Still a lot of noise there. You really have to tie any signal down with 100k or less.

Having said all that: remember, I'm just a hobbyist. What do I know... 😉

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/307edba8-39ba-3266-269f-06c47c24ade1%40makr.zone.

[Ian Arkver]

OP (Roman?) showed a pic of the scope trace in the first post. Doesn't look like interference to me. Definitely looks driven. Whether it's driven by the AVR is a question.

Regards,
Ian

[Roman Valls]

Ian, see https://github.com/markmaker/TinyG/pull/2, we solved it! (see last commit specifically) :)

We are soldering a pot and a 10k resistor now to adjust the ADC signal properly, but the annoying 100Hz signal is gone and the rest of the machine seems to (still) work fine :)

[Ian Arkver]

Yay! Good find.

Regards,
Ian

[mark maker]

>OP (Roman?) showed a pic of the scope trace in the first post

Duh, missed that ...

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/a2e1bedf-6c41-4756-8766-e6a00c891842n%40googlegroups.com.

[mark maker]

Cool!

But how does this make sense? Who would setup SPI chip select and a PWM on the same line? And what for?

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/aaf43586-41a4-48c8-ad6d-a8c0c1d00259n%40googlegroups.com.

[mark maker]

Anyways, I will integrate it as soon as I get that old AVR IDE setup running again...

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/06f7d6a0-2878-4d34-a51a-262a62a91f79%40makr.zone.

[Ian Arkver]

FWIW, I added a CMakeLists.txt to use regular Linux avr-gcc. I also fixed a couple of problems with static data declared in header files which leads to multiple definitions at link time.

I didn't generate hex or try running the compiled output, so I don't know if it's the same as the AVR IDE output. I had thought to try it under qemu-system-avr, but Roman found the problem first.

If you're interested in these changes I can push them somewhere, otherwise I'll ditch them.

Regards,
IanJ

[mark]

please make a PR! it would be nice to ditch the proprietary stuff. 

i‘m offline now

On 7 Feb 2023, at 12:06, Ian Arkver <ian.ark...@gmail.com> wrote:



To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/3db23abf-1001-48fe-90df-02bb2656c1b8n%40googlegroups.com.

[Roman Valls]

Good news folks! We finally managed to fix all our ADC issues, here's what worked:

1) 1-line change on the TinyG source code: https://github.com/markmaker/TinyG/pull/2/commits/5f16e42cd907930325bbc818d82ed080ba3bfeef . This change removes the 100Hz 90% duty cycle signal, without this change every now and then the ADC will saturate to max value (4095) for no good reason... I guess this works for Philip in the other thread (as mentioned on https://github.com/markmaker/TinyG/pull/3#issuecomment-1443558720) because the outliers get discarded via (OpenPnP) software, but it's clearly sub-optimal, this should be fixed, Mark... Ian, this is the only change you want to put in your TinyG CMake branch, for sure, now tested and validated. We tested the different ADC modes and determined that this one line change is the only thing needed to have stable ADC readings.

2) A multi-turn trim pot in series with our sensor AN (analog signal), we determined that at around 13.6 Ohms the signal is neither too low nor resonates, so we have around 400mV of range, which is more than enough for the ADC to detect vacuum/no vacuum via OpenPnP's threshold. We'll include such a trim-pot in a small board near the SS2 connector to adjust it properly and then hot-glue it when it's optimal (when the attached oscilloscope and M105 tell us so ;).

[mark]

was built with Cmake?

On 28 Feb 2023, at 20:22, Roman Valls <brain...@nopcode.org> wrote:



To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/751091b5-d9dd-4cca-92bc-da724afd7f0en%40googlegroups.com.

[Roman Valls]

No, that flashing and testing comes next Tuesday, sorry! ;)

[Ian Arkver]

Mark, do you want me to cherry pick Roman's one favoured commit into my branch, which is now more of a mop-up branch? Or would you prefer separate PRs?

Either is fine by me.

[Roman Valls]

I'd favor you cherry-picking that commit to keep history, your branch's commits and comments are of great value to the community and it's good to keep it one place, I reckon.

[mark maker]

> Mark, do you want me to cherry pick Roman's one favoured commit into my branch, which is now more of a mop-up branch? Or would you prefer separate PRs?

After having a closer look, I believe the change is not really a fix after all, it just removes the $p1frq setting from the EEPROM settings. 🤔

I guess one could likely just use the command

$p1frq=0

to disable the PWM output. That would also explain, why other users (including me) were able to use the ADC. See also here:

https://github.com/synthetos/TinyG/wiki/TinyG-Configuration-for-Firmware-Version-0.97#pwm-group-pulse-width-modulation

Removing the p1frq register also changes the layout of the EEPROM, which means users would corrupt their settings on updating to our new firmware. 😨

Furthermore, I'm not sure the pwm.c[PWM_1].frequency data field would be properly initialized (to zero), if it were no longer controlled by the p1frq setting. It could then well contain random garbage, so it would intermittently work when the garbage is outside frequency range as checked by pwm_set_freq(), and then sometimes not. See here:

https://github.com/synthetos/TinyG/blob/39df38c0e5830721fb2d16a7ae7b44816d24c4c4/firmware/tinyg/pwm.c#L145-L149

If possible, PWM should also still work in combo with the ADC. It should still go to the PWM output pin, some users might use it to dim the LED lights, or control the pump voltage, for instance.

I guess the actual bug is that the inner PWM source is currently mapped to the SS2 output pin for some reason. It would be cool to fix that instead of just disabling PWM altogether. The SS2 is not on the schematic, unfortunately. PWM is on PD5.

https://github.com/markmaker/TinyG/blob/feature/best-for-pnp/hardware/v8schematics/v8h/tinyGv8h%20-%20schematic%20page1.pdf

I have no idea how that pin mapping stuff works on an AVR, so I hope I can leave it to you, seeing you have a lot of experience with that avr-gcc stuff 😁

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/7e220cd1-bc96-4bd6-97bf-96c1abac6f1an%40googlegroups.com.

[Ian Arkver]

OK, not cherry picking.

Re: SS2 on the schematic - I think it is (on PB3), though it's maybe not a named net...

I think ensuring that no digital function is driving the output, and no digital input is reading it, should allow it to work as an analog input, but without a board to try it on I'm guessing.

Regards,
IanJ

[Ian Arkver]

Re; "Furthermore, I'm not sure the pwm.c[PWM_1].frequency data field would be properly initialized (to zero), if it were no longer controlled by the p1frq setting."

The struct is a global, instantiated here:

pwmSingleton_t pwm;

(not really a Singleton, just a global. This isn't C++)

Anyway C guarantees that global variables are initialised to zero at startup:

https://stackoverflow.com/a/16015741/14569828

It's still a hacky "fix" though and, as you say, breaks the config load order.

CU
Ian

[Philip Kristoffersen]

Hi,

Just adding my stuff for comparison,

Setup of the Oscolioscope:


Measurement pump ON:


Measurement pump OFF:


PWM Hz Settings:


My signal is stable, I watched it for a good few minutes and there is no deviation from what would be expected - I am not seeing anything that mimics a PWM signal or spikes to the same voltage range.

My TinyG V8 was first flashed with the official 420.20 firmware from TinyG, afterwards I flashed the 420.21 firmware onto the TinyG and then I have configured TinyG settings from there, but I have not touched anything other than motor settings.

- Philip

[mark maker]

> Re: SS2 on the schematic - I think it is (on PB3), though it's maybe not a named net...

 I must have been blind.😅

> I think ensuring that no digital function is driving the output, and no digital input is reading it, should allow it to work as an analog input, but without a board to try it on I'm guessing.

I have a board, but no clue where to look for outputs mapping. I found this...

https://www.electroschematics.com/avr-pwm/

.. but no OCR1A in the TinyG source.

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/aea53295-61e9-4f98-96a4-3026288ab42en%40googlegroups.com.

[Roman Valls]

That's precisely the reason why we were experimenting with PORT3.DIR directives: trying to make sure it's not configured as an output port, late in adc_init(), after all other main functions have been executed.

But we also were as confused as you going down the TinyG port abstractions... perhaps Ian has better code navigation skills and has managed to locate this one to make sure PB3 is not enabled as output somewhere else? :-S

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/555a275c-87d3-677e-5975-66f7fcee406d%40makr.zone.

[Ian Arkver]

I took a look at Atmel Start (start.atmel.com) and configured an XMega project with 2x ADC and told it to set up PB3 as an analog input (and called it an_in).

The generated code has this...

/* Configure pins and initialize registers */

void ADC_1_initialization(void)

{

// Disable pull-up resistor

an_in_set_output_pull_mode(PORT_CONFIGURATION_TOTEM);

// Disable digital // Disable digital input buffer

an_in_set_isc(PORT_ISC_INPUT_DISABLE_gc);

ADC_1_init();

}

I don't see anywhere where you use this input disable macro in your branch Brainstorm. Maybe I missed it.

For reference, an_in_set_isc is this...

/**

* \brief Set an_in input/sense configuration

*

* Enable/disable an_in digital input buffer and pin change interrupt,

* select pin interrupt edge/level sensing mode

*

* \param[in] isc PORT_ISC_BOTHEDGES_gc = Sense Both Edges

* PORT_ISC_RISING_gc = Sense Rising Edge

* PORT_ISC_FALLING_gc = Sense Falling Edge

* PORT_ISC_INPUT_DISABLE_gc = Digital Input Buffer disabled

* PORT_ISC_LEVEL_gc = Sense low Level

*/

static inline void an_in_set_isc(const PORT_ISC_t isc)

{

PORTB_pin_set_isc(3, isc);

}

XMega doesn't seem to have explicit pinmuxing, rather the alternate function that uses a port seems to be determined by which peripherals are enabled. Using Start to explore startup code looks like a good pointer.

All the best,
Ian

[edited]

[Roman Valls]

Despite the CMake-avr-gcc branch from Ian didn't compile on OSX: https://github.com/markmaker/TinyG/pull/3#issuecomment-1458064732

I ssh'd to a Linux server, compiled there and flashed it... OpenPnP connects to the board but on $$ one can see that most of the settings got garbled:

https://pastebin.com/zJqeKJTG

AND the 100Hz signal is back! AND it cannot be disabled with $P1FRQ 0 on the console.

[Ian Arkver]

My branch contains no ADC code and nothing to try to disable the PWM output. I haven't looked to see what happens if PWM Freq is set to zero and how exactly the TinyG code sets up PWM1 to drive PB3.

If you flashed code onto a chip that had settings saved with your commented-out PWM version that might account for the shift/breakage in settings. Or it might be something else (eg. difference in assumed sizeof(int) for example).

My branch was simply supposed to be an alternate way to compile the existing code.

Regards,
Ian

[markmaker]

> $P1FRQ 0

Yes and be sure to use the right syntax  afaik it is case sensitive and you need the = to assign.

_mark

[markmaker]

Forgot this
https://github.com/synthetos/TinyG/wiki/TinyG-Configuration-for-Firmware-Version-0.97

[Roman Valls]

My last test with all this was to flash makr.zone original ADC-enabling .hex and the machine now works *and* the 100Hz signal is gone, which now we can conclude that:

1) The 100Hz seems to be a stray EEPROM setting, that I couldn't switch to 0 regardless of the correct syntax of the command (thanks Mark).

   1.1) Funny side effect of typing P1FRQ command with the "wrong" syntax on the console: the whole OpenPnP java app locks up :shrug:.

2) Is there a way to reliably set "reasonable defaults" on that EEPROM when flashing Mark's firmware? The answers I found doesn't seem straightforward (i.e https://electronics.stackexchange.com/questions/531171/can-i-safely-erase-the-eeprom-on-my-atmega2560-by-flashing-a-hex-file-where-ever), but you might know an alternative way?

Anyhow, case closed for now, I reckon ;) Here's my current OpenPnP machine config for reference: https://github.com/CCHS-Melbourne/Pick-N-Place/commit/5c0e21463acbfe57171499069257ca6447985503

Thanks for the followups and help Mark, Ian and Philip!

I reckon that Ian's branch could potentially be merged as-is, Mark, it'll benefit other folks that might wish to modify TinyG's firmware without Atmel Studio.

[mark maker]

> 1.1) Funny side effect of typing P1FRQ command with the "wrong" syntax on the console: the whole OpenPnP java app locks up :shrug:.

Yep, the console is very simple. Until it receives an "ok" it will simply hang, only to be relieved by the timeout.

> The 100Hz seems to be a stray EEPROM setting, that I couldn't switch to 0 regardless of the correct syntax of the command (thanks Mark).

Maybe it was another option, or maybe multiple options have the effect of enabling the PWM. Do you still have the $$ dump?

Whatever it is: I guess the PWM pin mapping is faulty, i.e. even with PWM enabled the ADC should still work. And unless someone with AVR knowledge comes along, I guess we're stuck.

I haven't forgotten forget Ian's fork, just no time to test on the board anytime soon (this will likely be more than a 10 minute endeavor).

_Mark

--

You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/4d5b2f66-7805-4767-8495-02cd4181763fn%40googlegroups.com.

[Roman Valls]

On Thu, 16 Mar 2023 at 22:46, mark maker <ma...@makr.zone> wrote:

> 1.1) Funny side effect of typing P1FRQ command with the "wrong" syntax on the console: the whole OpenPnP java app locks up :shrug:.

Yep, the console is very simple. Until it receives an "ok" it will simply hang, only to be relieved by the timeout.

Sure, but is it really necessary to lock the whole UI? I'd expect the UI to be running on a separate thread and not lock up?

> The 100Hz seems to be a stray EEPROM setting, that I couldn't switch to 0 regardless of the correct syntax of the command (thanks Mark).

Maybe it was another option, or maybe multiple options have the effect of enabling the PWM. Do you still have the $$ dump?

I’ll collect that next week, but it’s similar to the pastebin link I posted earlier, just a bit less broken and enough to have a working machine…

Whatever it is: I guess the PWM pin mapping is faulty, i.e. even with PWM enabled the ADC should still work. And unless someone with AVR knowledge comes along, I guess we're stuck.

I haven't forgotten forget Ian's fork, just no time to test on the board anytime soon (this will likely be more than a 10 minute endeavor).

Indeed, if you don’t have the board already setup it’s a bit more tedious  :/

You received this message because you are subscribed to a topic in the Google Groups "OpenPnP" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openpnp/0tcJh1ygayk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openpnp+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/828b68df-209a-2340-ca7c-ca5169479740%40makr.zone.

[mark maker]

> Sure, but is it really necessary to lock the whole UI? I'd expect the UI to be running on a separate thread and not lock up?

I guess it is veery old code.

This is just written as blocking ping pong, i.e. only after it sent a command, it expects at least one response and then sends it to the console output. You would have to rewrite it from scratch to constantly monitor responses and just put them into the console whenever (and if ever) they arrive. I.e. add a listener interface on responses in the driver. And it would probably have to carefully add/remove itself as a listener to only be active when the Console tab is on top. Otherwise it would put a performance penalty on the whole driver comms.

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CAOpFiqs91khr%3D-QmfKHqCqqtvAB4avKHFnfRxyjZMkjy4fMSgA%40mail.gmail.com.