AMXTools

PhreaK

Does anyone know where the latest version of the AMXTools (com.amx.duet.tools) libraries can be obtained from?

PhreaK

*bumpity bump bump bump*

About to start on a new batch of modules and would be nice to grab any version newer than v2.0.35 (released in '08). Bueller?

Any of the ITG guys still lurking on the forums?

cwpartridge

Here is the most recent version. This is unsupported code and is no longer being maintained.

2.0.36 (January , 2009)

---

- Fixed handleTimerEvent() in DeviceUtil.java to call reinitialize() inside the
conditional and removed the line of code which set the Online state to false.
The user is responsible for setting whatever Online/Initialize values are appropriate
inside the reinitialize() method w/in the module. This will allow greater flexibility
and consistency.
- Updated the System_Diagnostic routine w/in the DeviceUtil.java class and added method isInDiagnosticMode()

PhreaK

Awesome thanks. As this is depreciated is there a replacement toolkit (or one in dev) which takes its place?

cwpartridge

There is no replacement or plans for one.

Auser

Soooo, what does this mean for the future of Cafe Duet? Is Cafe Duet still being actively maintained? If I was thinking of rushing out and buying a couple of licenses, should I?

[Deleted User]

Cafe Duet

Auser wrote: »

Soooo, what does this mean for the future of Cafe Duet? Is Cafe Duet still being actively maintained? If I was thinking of rushing out and buying a couple of licenses, should I?

\

AMX is comitted to Cafe Duet as the development platform for AMX and third party device control. The current application was updated about 1.5 years ago along with the API, you should see another release this year. Your purchasing decision should be based on your needs and development preference. If you prefer writing code in java, this is the way to go. If you are a manufacturer and wish to write your own Duet modules rather than provide AMX with your protocols, this would be your best approach. If you are comfortable with NetLinx programming language and use the Duet modules, there is no need to purchase Cafe Duet.

Auser

Doug Hall wrote: »

The current application was updated about 1.5 years ago along with the API, you should see another release this year.

Thanks. Will the next release be free to existing Duet license holders or will there be a fee to upgrade?

jjames

I'd like to know why there isn't a "demo" for those of us who don't have it. Heck, disable the ability to create JARs or something just so we can use it and see if it'd be worth spending an arm and a leg for it.

[Deleted User]

Cafe Duet Upgrades

Auser wrote: »

Thanks. Will the next release be free to existing Duet license holders or will there be a fee to upgrade?

No charge for Cafe Duet Upgrades.

Anarckos

which the main advantages Cafe Duet offers me over the NetLinx? I know that one of them is the Java language. but I wonder about the internal functions of the AMX, control equipment ... what advantages?

Sorry for my english. Translated by Google.

DHawthorne

Anarckos wrote: »

which the main advantages Cafe Duet offers me over the NetLinx? I know that one of them is the Java language. but I wonder about the internal functions of the AMX, control equipment ... what advantages?

Sorry for my english. Translated by Google.

The main advantage is being able to use Java libraries, and presumably an easier migration for pre-existing Java programmers. And I do mean migration ... because a Java programmer with no control system integration experience can really make a hash out of a device module. It can be considerably faster if there is a lot of code manipulation, but as for talking to devices, etc., NetLinx works just as well, if not better.

PhreaK

If your writing systems that are based around the 'push a button, this happens' concept, there's no argument - NetLinx wins hands down. It's simple efficient and easy to pick up. This comes at a price though - it's essentially a scripting language. If you're after any sort of inter component interaction and complex behaviours it's possible, but extremely hard to implement and a nightmare to maintain. Java is a full object orientated language and provides all the benefits that come with.

In the end they're both just tools. No matter what language you're using the goal is to combine a number of discreet components into a singular cohesive experience for the user. It's the design of how this happens (along with the matching of components for system performance) that makes or breaks a system. The master is going to behave the same way, it just what's going on behind the scenes that's different.

Anarckos

I imagine that would make Java programming more elegant. my fear is that it can be very slow to develop, I imagine that would need to create objects to be referenced to the AMX devices, such as REL-10, Radia ...
Do not know if there is some sort of SDK for Java AMX.

ericmedley

Anarckos wrote: »

I imagine that would make Java programming more elegant. my fear is that it can be very slow to develop, I imagine that would need to create objects to be referenced to the AMX devices, such as REL-10, Radia ...
Do not know if there is some sort of SDK for Java AMX.

Java SDK for AMX = Cafe Duet

Anarckos

ericmedley wrote: »

Java SDK for AMX = Cafe Duet

Heheheh, Tanks Eric!

alPrihodko

Features request

We need to perform some actions on NI using Duet:
- reboot the master controller
- get size of internal queue

There are similar functions called REBOOT() and INTERNAL_QUEUE_SIZE_GET(CONSTANT LONG A) described in NetLinx.axi
I wonder can this functionality be accessed from Duet level and how it can be accomplish.
Any ideas? Thank you

ericmedley

Anarckos wrote: »

Heheheh, Tanks Eric!

not a problem.

PhreaK

Haven't had the need to do those things natively in duet as of yet, but one technique I've found for accessing NetLinx only functions (or even wrapping whole closed source NetLinx modules *cough* RMS *cough*) is to capture events from the virtual device within the module stub and act on it in there.

Basically you set up a data event handler for the virtual device within the stub and then use it to communicate from the duet side of your module to the NetLinx side. The nice thing about this is that its all contained within the stub so it remains encapsulated. For things where you need to pass data back (in your case the result of INTERNAL_QUEUE_SIZE_GET()) you then shoot this to the virtual device from within the stub, catch it in duet and forward it on to your callback function. Works a treat.