ITER Hardware

Discuss the technical details of an "open source" community-driven design of a polywell reactor.

Moderators: tonybarry, MSimon

Post Reply
MSimon
Posts: 14334
Joined: Mon Jul 16, 2007 7:37 pm
Location: Rockford, Illinois
Contact:

ITER Hardware

Post by MSimon »

Dr. Louis Giannone, a research scientist for the Max Planck Institute for Plasma Physics in Garching, Germany is working on an upgrade to the ASDEX (Axially Symmetric Divertor EXperiment) divertor tokamak in Garching. The project has been able to take advantage in the multicore enhancement provided in LabVIEW 8.5. "In the first design stage of our control application programmed with LabVIEW, we have obtained a 20X processing speed-up on an octal-core processor machine over a single-core processor, while reaching our 1ms control loop rate requirement."
http://www.eetimes.com/news/latest/show ... =201300360

Thoth
Posts: 8
Joined: Sat Aug 25, 2007 6:19 pm

Post by Thoth »

We use LabVIEW for most of our projects, at least at the prototype stage. Some we eventually transition to embedded processors, others keep using LabVIEW. It really is a remarkable toolset. I think it would be an excellent choice for Polywell control. Where the wheel doesn't have to be reinvented...

BTW, I have no affiliation with National Instruments.

MSimon
Posts: 14334
Joined: Mon Jul 16, 2007 7:37 pm
Location: Rockford, Illinois
Contact:

Post by MSimon »

I have used LAB View for various projects. It is not bad.

However, the last time I used it I thought it was rather slow. Update rates of 100 Hz or so on the overall loop.

Good for a quick and dirty look at something or testing slow processes. Not so good once control rates get up into the 1 KHz and above range.

Plus, because it is PC based the control loops are not time deterministic which adds noise to the control loop.

As an overall control system - turning on motors, controlling coolant flow valves, collecting system temperatures and flow rates, etc. it would be just fine.

tonybarry
Posts: 219
Joined: Sun Jul 08, 2007 4:32 am
Location: Sydney, Australia
Contact:

Post by tonybarry »

Hello Simon,
For the stuff you have been posting about, LABview is too slow. I expect your control loops will have to run in real-time-operating-systems, and maybe even in direct analog feedback loops. Way beyond my experience. Though your SEAforth chip might manage some of it. The A/D will be the bugbear. Getting a gigasample/second is no mean feat. and that's often at a few bits resolution. Depending on your necessary resolution, you might have some analog pre-processing needed.
But I look forward to the details ...
Regards,
Tony Barry

MSimon
Posts: 14334
Joined: Mon Jul 16, 2007 7:37 pm
Location: Rockford, Illinois
Contact:

Post by MSimon »

Photo multiplier tubes have response times on the order of 1 nS.

Sampling at up to 100 MHz with off the shelf A/Ds with >10 ENOBs is not a problem. That should be fast enough to control electron injection.

In fact that same A/D can actually sample at >500 MHz if you limit the bandwidth to 100 MHz.

A fast variable gain amplifier as a front end should extend the range of power that can be detected. A 128 to 1 range should do the job.

Thoth
Posts: 8
Joined: Sat Aug 25, 2007 6:19 pm

Post by Thoth »

Yes. For most of the hard real-time stuff we stick to embedded devices with QNX.

I haven't investigated this yet but there is a LabVIEW real-time module. No idea what performance looks like.

MSimon
Posts: 14334
Joined: Mon Jul 16, 2007 7:37 pm
Location: Rockford, Illinois
Contact:

Post by MSimon »

Let me quote a short bit from a friend of mine who works for a FORTH tools company.
After visiting a bunch of companies with the CEO here we were asked many times, “But what do I do with my 500 C programmers?”

This led the CEO to a joke. How many programmers does it take to change a lightbulb?

500, I know because that’s how many everyone has. It must take 500 of them to do anything!

Perception becomes reality.
The productivity gains from FORTH are astounding. And to most people unbelievable. And even for those who believe it presents problems.

Given that production speed is critical as is keeping the total team small, I'd say that FORTH is the best choice.

As the joke among FORTHers goes:

"You don't realize the power of the FORTH."

Roger
Posts: 788
Joined: Fri Jul 06, 2007 2:03 am
Location: Metro NY

Post by Roger »

MSimon wrote:
"You don't realize the power of the FORTH."
Groan.
I like the p-B11 resonance peak at 50 KV acceleration. In2 years we'll know.

MSimon
Posts: 14334
Joined: Mon Jul 16, 2007 7:37 pm
Location: Rockford, Illinois
Contact:

Post by MSimon »

Sun Micro uses FORTH (now called the Open Boot Standard - IEE Std 1275) on all their terminals.

http://playground.sun.com/1275/home.html

It is the best darn hardware debugger there is.

Even if we use some other language for production code (as Sun does), like Sun, I'd like a FORTH for hardware debugging.

Post Reply