Home› AMX User Forum› NetLinx Modules & Duet Modules

Duet Master Firmware & Non Duet Master Firmware

SensivaSensiva Posts: 211
in NetLinx Modules & Duet Modules
Hello all

I don't use duet modules, and not planning to do in the near future.

Do I still need to install Duet firmwares? or I can go with Non Duet firmwares?

in other words..

Is Duet firmware for duet modules only, or it is used for other purposes?

Thanks
Sensiva

Comments

  • DHawthorneDHawthorne Posts: 4,584
    You don't need it. However, if the master supports it, I would install it anyway. It doesn't hurt anything, and if you run into one of those situations where suddenly you have no choice but use a Duet module, you are ready for it. Even if you do no Duet programming at all yourself, some of the modules can be handy (like the virtual keypad that runs on a PC).
  • Jimweir192Jimweir192 Posts: 502
    You certainly can use the duet firmware versions for non duet projects (obviously not the opposite). I've not noticed any delayed loading with it, unless you have duet modules...

    Certainly looking at things in the last year or so, Duet F/W has been developed but non-duet has been minor fixes only
  • annuelloannuello Posts: 294
    One thing I believe you need to be aware of with Duet firmware is to ensure that it has enough memory allocated to it. After upgrading the firmware, telnet into the master & type GET DUET MEM. By default it can be as low as 1Mb - I bump mine up to 6Mb. I could be wrong but from what I understand, the web server that hosts the built in administration pages runs under duet. Without sufficient memory allocated it tends to choke up.

    Having said that, I wish I could downgrade to non-duet firmware. While new features seem to be duet only, there are several bugs that drive me crazy:

    1. Persistant variable are not always persistent. As such I save/load all my persistant variables in XML files.

    2. The FTP server has changed the "group" attribute to "0" in the directory listings, which causes grief with some FTP clients.

    Roger McLean
    Swinburne University
  • SensivaSensiva Posts: 211
    annuello wrote:
    1. Persistant variable are not always persistent. As such I save/load all my persistant variables in XML files.

    That's gotta hurt!

    I was thinking if I could use non duet firmware because Duet firmwares extends boot time very much.
    So i thought non Duet will improve boot up performance

    but since Non duet has such a bug... I am Happy with Duet now :)

    thanks to you all for making things clear.

    Sensiva
  • Joe HebertJoe Hebert Posts: 2,159
    annuello wrote:
    Having said that, I wish I could downgrade to non-duet firmware. While new features seem to be duet only, there are several bugs that drive me crazy:

    1. Persistant variable are not always persistent. As such I save/load all my persistant variables in XML files.
    Can you duplicate the non persistent variables bug? When aren't they persistent when using DUET? You have me worried now. :(
  • Spire_JeffSpire_Jeff Posts: 1,917
    The only times I've had problems with persistent variables is: In Modules (not allowed to the best of my knowledge) and when I change something in code and send the new code to the processor (This only happens when the compiler decides the persistent variable has changed ... as far as I know.).

    I would be interested in hearing about any other problems, but most of the persistent stuff I deal with is done in XML files so that I can move the data between processors (favorite info and similar stuff). This also comes in handy if a power surge blows up a processor.... you can just put in a new processor and send the most recent xml file you have :)

    Jeff
  • annuelloannuello Posts: 294
    Just clarifying, I've only seen the persistent variables bug on duet firmware, not on the non-duet firmware. The persistant variables were not in modules (which doesn't support persistence anyway). Some PVs were in the main file, while others were in included files.

    All PVs were dropped after:
    1. Uploading a new program (with reboot).
    2. Issuing the reboot command
    3. After power failure.
    Hmmm... Thinking about it, that sounds more like the PVs are not being reloaded from flash correctly, rather than being 'dropped' mid flight. However, it didn't happen every time in each of these cases. Unfortunatly it is one of those painful bugs that I can not consistently reproduce.

    Perhaps I am a bit bold in claiming that it is a duet bug - the bug may not be spread across the whole duet scope, but may be pertinant to a particular model. I've noticed it on at least four of my NI-3100 masters running v3.21.254. What I DO remember is that this never happend in my pre-duet days. Needless to say, the pain was so great that I went the XML approach, ceased using the PERSISTENT keyword, and never looked back. I agree that the XML aproach is great for similar (yest slightly different) settings across a large number of venues.

    Roger McLean
    Swinburne University
  • SensivaSensiva Posts: 211
    mmm....

    there are some rules to retain variables persistence after new program download, regarding reboot or power failure... I didn't experience anything wrong with persistent variable...

    I thought you were saying these bugs are in Non duet..... that's why I took off using non duet out of mind.
  • annuelloannuello Posts: 294
    The only rule that I'm aware of is that to retain persistant variable values between code updates, the name (& probably the data type) must stay the same. All I was doing was minor code updates here & there without shifting/renaming PVs around. Even so, that still doesn't account for the PVs being dropped after a power failure (where there is no code change). Perhaps I have an unlucky batch of masters. :( At least I have XML files. :)

    Roger McLean
  • TurnipTruckTurnipTruck Posts: 1,485
    With an NI-x000 controller, the Duet firmware starts up MUCH slower. If you are uploading a quite a bit while testing, etc, you will get sick of waiting real quick. I put the Duet firmware on my NI-2000 at home and switched back to Non-Duet after a few code loads. Unless you want to run Duet modules (which I still don't fully understand the wisdom of) I see no reason to run Duet.
  • annuelloannuello Posts: 294
    I was under the impression that, once you load duet firmware, you can not downgrade back to the non-duet version. Is this correct, or is the non-downgrade issue just between vXXX & vYYY of duet?

    Roger McLean
  • TurnipTruckTurnipTruck Posts: 1,485
    Not sure if there is an official answer, but it worked for me on an NI-2000.
  • CT-DallasCT-Dallas Posts: 157
    Jim is correct above when he states that the non-duet firmware updates have only been minor changes and the duet firmware has seen major updates.

    We have been experiencing problems with MVP's falling off line and not being allowed to reconnect to the master. They remain online in the internet connection sense, but are not online with the master.

    The project is fairly high profile and several top engineers from AMX came out to the site to assist us in resolving it. We were using the most current non-duet firmware and still having problems. Although we are not running duet modules, we were instructed to upgrade to the duet firmware. Apparently, there were multiple fixes for TCP/IP communication in the duet module firmware release. It seems that most of the engineering efforts are going into the duet firmware releases, and as a result, we will see a taper off of non-duet releases.

    After a week of observing the panels, the connectivity problems have essentially gone away. We still miss blink messages on occation, but the firmware fixed an issue where the master would retry after x amount of missed messages. This allowed the panel to reconnect to the master.

    So in short - even with a longer boot time, I think we are going to be installing the duet firmware moving forward. We will certainly do this when there are MVP's on the job.

    Chris
  • TurnipTruckTurnipTruck Posts: 1,485
    I have seen problems with earlier Duet firmwares on busy networks. There is also some Cisco protocol used to communicate within their hardware networks that can wreak havoc with Netlinx masters. I've used routers to isolate Netlinx from the network only allowing port 1319 traffic and all the problems were solved.
  • Joe HebertJoe Hebert Posts: 2,159
    annuello wrote:
    Just clarifying, I've only seen the persistent variables bug on duet firmware, not on the non-duet firmware. The persistant variables were not in modules (which doesn't support persistence anyway). Some PVs were in the main file, while others were in included files.

    All PVs were dropped after:
    1. Uploading a new program (with reboot).
    2. Issuing the reboot command
    3. After power failure.
    Has anyone else experienced this problem? I tested Persistent variables on 2 - NI-4100s and 1 - NI-700 running the latest and greatest DUET firmware (v3.30.371) and I haven't been able to duplicate any type of Persistent variable bug.
  • Spire_JeffSpire_Jeff Posts: 1,917
    I wonder if there is something happening in either the DEFINE_START section or when a device comes online that is resetting the persistent variables???

    I haven't had any problems where there shouldn't be any with persistent variables, but I don't really use them often.

    Jeff
  • JOHNBONZJOHNBONZ Posts: 99
    Waiting on Duet

    Has anyone resolved the issue of uploading and waiting on Duet? I have a NI-2000 and it sits for 45 seconds which adds to the uload time.There has got to be a way to "turn it off".
Sign In or Register to comment.