Options
NX Series Masters
ericmedley
Posts: 4,177
Well, I'm playing with one of the new NX 3200s and I must say I'm pretty happy with it. Some of the bench tests I've ran clock it in at anywhere from 10-30 times faster than the same test on an NI. (depends on the task)
I like the leg room of the memory.
I REALLY like that AMX came up with a standardized port assignment for all the devices on the different controllers (for example no matter the number of ports and whatnot, the relays are always on port 21)
That way porting code from one kind of master to another doesn't necessarily break your device addressing.
The 2nd NIC (ICSLan) is an interesting feature and will help with systems using several EXB boxes. While this same port is useable for Touch Panels, I don't see it as being practical since most every one of my UI need to have access to the outside world network for dynamic images and so forth. But, it is there and can be used if the need arises. This will be particularly helpful when working in facilities with crabby IT department heads running around waving network security protocols in your face. Just throw all that chatty stuff on the ICSLan port and nobody will know any different.
Getting rid of the D-sub9 (DB9) serial ports is a plus in my mind. It saves space and eliminates all those pesky adaptors. I could see one little train wreck with non-technical sales people types. only two of the serial ports are truly 422/485 capable. The rest are simple 232 ports. (TX,TX,Gnd) It will require riding herd a little more closely when figuring out what all serial devices are present and making sure that we don't run over budget on 422/485 enable ports. No biggie, I'm being pretty picky here.
How it behaves in a real system remains to be seen. I might install this one on my personal system for a while to see how it handles more real-world tasks before deploying one onsite.
But, so far I'm happily impressed.
I like the leg room of the memory.
I REALLY like that AMX came up with a standardized port assignment for all the devices on the different controllers (for example no matter the number of ports and whatnot, the relays are always on port 21)
That way porting code from one kind of master to another doesn't necessarily break your device addressing.
The 2nd NIC (ICSLan) is an interesting feature and will help with systems using several EXB boxes. While this same port is useable for Touch Panels, I don't see it as being practical since most every one of my UI need to have access to the outside world network for dynamic images and so forth. But, it is there and can be used if the need arises. This will be particularly helpful when working in facilities with crabby IT department heads running around waving network security protocols in your face. Just throw all that chatty stuff on the ICSLan port and nobody will know any different.
Getting rid of the D-sub9 (DB9) serial ports is a plus in my mind. It saves space and eliminates all those pesky adaptors. I could see one little train wreck with non-technical sales people types. only two of the serial ports are truly 422/485 capable. The rest are simple 232 ports. (TX,TX,Gnd) It will require riding herd a little more closely when figuring out what all serial devices are present and making sure that we don't run over budget on 422/485 enable ports. No biggie, I'm being pretty picky here.
How it behaves in a real system remains to be seen. I might install this one on my personal system for a while to see how it handles more real-world tasks before deploying one onsite.
But, so far I'm happily impressed.
0
Comments
Our boot and file load/reset time is well less than half that of a 2100/3100... under 2 minutes.
Why so long, you ask? We dynamically load over 150 files that make up system information.
Which brings me to an annoying need to manage file extension case where we didn't before.
So files with .CSV instead of .csv are not found. Not a big deal, but since it historically didn't matter, various parts of our code played loose with this and a few places read .csv but later write the same file as .CSV, so it works ONCE. Lazy programming, not hard to clean up, just something new, more to do.... and to warn the dealers about editing the data with something that saves with caps.
Did I mention FAST?
And soooo much memory. Too bad the compiler still limits you to 100,000 variables, which sounded like a lot when it was written for a 16 meg ram model in 1998. Now that there is as much as a gigabyte of ram to play with, it's pretty much unavailable to program in.
The user-visible effect of the speed is pretty hard to notice, as now the render speed of the panels are the limiting factor. If you have computation-bound or parsing delays, these will help a whole lot.
For example, we parse VOICE CONTROL through a 1,500 item match table. That takes about 2 seconds on a 3100, so worst case it takes 2 seconds to return "Sorry, I don't understand". With this unit, it looks like we could do 3,000 entries in under 1 second. If we could afford the variables.
UPDATE: The NX searches 1500 entries for a voice match in 1/5th of a second... give or take.
I don't like the way your talking about my modules...
Maybe it was one of mine... :lol
It seems like you would know the answer to this question, wether you are at liberty to discuss is another matter.
What is the deal with writing Duet modules on the new masters? Specifically how do we take advantage of Java SE 1.7???? I have been told all the AMX class libraries are the same so everything written before should be compatible. I am excited to be rid of CEEJ, it was full of bugs and classes that just didn't work. Is there an update to Cafe Duet coming out? If you are not able to discuss, any idea when this will become public knowledge?
Well... I am not really sure what AMX will be doing as far as a DUET refresh. It has been almost 4 years since I left AMX. But from some of my old buds, it seems that the refresh will not be coming in the near future.
However, the modules I create still need to be backwards compatible with the 1.4 Java runtime environment. Also Cafe Duet is still locked to using 1.4 java syntax. Can this be changed, maybe?
However if you want your modules to be only compatible with the new controller, you actually start using some of the publicly available libraries out there that are compatible with the new JVM.
One of the hardest things I fight with is finding the libraries that work in the 1.4 ME environment.
I just got my first NX, and have been testing some of my modules, and enjoying the speed of this new controller.
Jeff