Mindboards

Helmut, what you want, is something far more complex than what is available at this time. The way you want it to work, it would require a complete new level of SW structure. You have already been told that such a library doesn't exist as far as any of us know, so please accept that and move on.

And yes, I agree 100% with Xander about your choices.

ok, thanks, one more expert who does not know. You also may move on if you like.
Anyhow, at least Linus had a vague idea or an imagination of how it might work. Maybe someone can translate it into action one day.

Does not know what? How to build the library? or if such a library exists?

I'm quite confident I know how to build the structure, but I'm also sure I don't know of an existing library that would fit your needs.

simply read the TOP!

I did, and the answer is no.

I was afraid of it.
Anyhow, according to statements made by "experts who should know" it is actually at present not possible to write a program in NXC, which could solve the problem of a multi-threading-safe multiplexer via BT network reliably.
So it would be very interesting to figure out if any other software based on another fw (like Lejos) is more advanced - or whether the NXT is simply a fundamentally inadequate hardware base for this requirement.
I started a thread in our German forum to check this out by a test model.
I'm not sure if any of our java programmers is ready to take the challenge.

doc-helmut wrote:Anyhow, according to statements made by "experts who should know" it is actually at present not possible to write a program in NXC, which could solve the problem of a multi-threading-safe multiplexer via BT network reliably.

I'm pretty sure it's possible, I think there are people out there who could do it, and I count myself among those people. The performance of such a system would have to be evaluated. The 30ms penalty for switching between BT RX and TX modes is a given fact, but other than that I see no limit (on throughput for example).

I myself have done BT multi-threading in MotorControl: The "main thread" does bi-directional BT communication, and there are up to three threads to do processing and motor control. A multiplexing protocol on top of this architecture is missing, but the technical basics are all there.

As people pointed out, the task is a complex one, and I agree. Modern development tools and processes (OOP, design patterns, best practices, ...) help to reduce and manage this complexity. I think your 3-years-failure is more a result of your attitude, and not of a lack of technical skill. You don't seem to follow other people's (often expert's) advice, and instead try to convince them to not convince you.

Software development is very related to personal character development, the ability to question oneself, to throw everything away and do it another way, and to learn new things. There is so much literature on this topic, e.g. http://www.codinghorror.com/blog/2004/0 ... world.html and the sources/links posted there (e.g. "The humble programmer", "Code complete"), as well as "The Clean Coder".

I'm just posting this here because I think this may be the root cause of your problem.

the TO question was not how or if it might be possibly done somehow by which strategies ever by someone some day in the future.
What I wrote about any failures or malfunctions have been only answers to questions what I already tried on my own but that was not related to any future approaches

The TO question was:

doc-helmut wrote: is already a multitasking-safe BT network available for NXC which does not block sending/receiving queues?
It should be able to
- initialize remote sensors (and remote sensor multiplexers)
- read remote sensors (and remote sensor multiplexers)
- control remote motors (and remote motor multiplexers) including related encoder counters
- send and receive any variable value calculated by any a remote procedure

that was the question, and e.g. mattallen37 wrote

mattallen37 wrote:...the answer is no.

mattallen37 wrote:what you want, is something far more complex than what is available at this time.

so if this is the final answer, this thread can be closed.