BobC

Just to bring you up to speed: https://en.wikipedia.org/wiki/Modal_window

Thank you Nick, I'm glad this made some sense to someone

Modes have nothing to do with it, again, escribe does nothing on the chip, it's a pure communications interface with a UI slapped on it, and I'm not sure where your UI best practice is derived from, but it sure isn't anything I've seen subscribed to in my experience, the UI should be geared to (and only to) the user experience, and the diverse needs of all consumers. Last post on this, I'm speaking to actual development best practices, not layman's theory, YMMV

not an upload, just a send of the override value, try it on the atomizer analyzer, the results are instant, but you are correct, you can in fact: 1.) open the Atomizer analyzer and change override value 2.) close atomizer window 3.) open Device monitor and view results of the change 4.) Close Device Monitor 5.) open the Atomizer analyzer and fine tune override setting 6.) close atomizer window 7.) open Device monitor and view results of the change Or you can................. 1.) open the Atomizer analyzer 2.) open Device monitor 3.) move to Atomizer analyzer and adjust setting 4.) see results instantly in the DM window

Nothing additional would be necessary at the device, firmware or hardware, remember, escribe is only a communication interface to the DNA200, with a user interface for value display and editing, we are purely speaking of software development best practices for user interfaces. As far as an example of an extreme advantage, how about the ability to update atty override value and see the results in real (near real) time

Actually, if it's programmed correctly, the user wouldn't even notice in most instances with exception to upload, which should cause a freeze on everything due to IO blocking for the load and disconnect from the reboot. Proper programming would enable IPC messaging so processes can listen for the load message and manage user notification and the restart

You're not a developer then, trust me, quality user interface coding doesn't work that way, you don't have to go enabling/disabling all the reads and writes all over the place, those functions should be developed as common modules/components/objects. It only depends how well you program the app, reads and writes can all be blocked calls, with resource locks maintaining resource integrity, it's not a new concept. Secondly, with the advent of mobile platforms, and decreasing relevance of the traditional desktop/laptop, it was extremely short sighted to implement escribe wired directly to a single operating system, I'm sure I speak for most in wanting an android/Iphone version of escribe if only for setting /reading settings and usage

As a technology senior executive in the financial community for 35 years, having managed development of applications on platforms ranging from mainframes to smartphones, the use of modal windows are the result of poor software design, not application/hardware requirements, as any restrictions can easily be implemented using resource locking in a multi-threaded environment. Please understand, Escribe is nothing more then a communications interface built specifically for the win32 graphical user interface, that's the problem, and as I stated before on this forum, the only reason it hasn't been ported to OSX and the mobile Linux environments of Android and IPhone, as that effort requires a re-write of the software.

Hate to tell ya buddy, real or what ever you call them, they're 10 amp batteries, toss em https://www.e-cigarette-forum.com/forum/threads/the-green-30a-3500mah-imren-is-a-10a-battery.723720/

don't know what hardware interfacing escribe performs, as my perception is, it's purely a communications interface with a GUI. The problem in the port to other OSs would have nothing to do with the DNA200 itself, but would depend on how deeply it is coded to the Windows api, that's the only challenge in the port

So, some random initial boost. Curious, do you not like the TC wire options (NI,TI,SS etc) ?

In getting back to the request at hand, wouldn't you need to be able to measure temperature to manage preheating? If you're not in Temperature mode, how do you see preheating working?

Check for a bad/cold solder on the pin 3 connector to the board

Movin on, nothing to see here

Works fine for me with a clean install

Only if you have Turbo skillz (and a machine shop), BTW, you'd be tremendous as a mod builder,

Nice work Turbo, that's definitely workable Where do I put my order in?

Anybody have a Haute Couture wheel barrow to carry a 3s2p mod? Maybe bedazzled (for fashion sense)

This is why this guy is amazing, I bet if ground is common, it works!

Scoop, saw them way before he posted here, it's why I was talkin to him, I appreciate the alternatives offered, but I'm looking for small, a single easily replaceable 18350 is all I want, size over power is everything to me, though that 3s config is replaceable, I wouldn't try it walking through Wall street, which is what I do every day

Scoopy, have you looked at Turbo's work? How he designed the 3s 600? Not so easy, I haven't seen the insides on his 2s design, so that's why I asked him. The size of the current DNA40 devices currently use are not much bigger then an 18650 bat plus a bottle: That's what I'm looking to stay with, with the features of the DNA200

I'm sure Turbo, but in reality, I rarely hover over 20-30 watts myself (and I see your Chalice, and know you're not going too high with that RDA), so 2S would be fine for me. Show us the finished mod when done, can't wait to see it. John, I hope it's sooner rather then later, I'd be stocking up on em

So John, how's the DNA60 ES coming along?

Damn Turbo, you have amazing skills buddy, How you going to cover the DNA on the 3S 600 Woodie convert?

Scalpel ! JK, check for cold solders, the connection may look solid, but if cold soldered, kinda hollow and pitted