converting AXCENT 3 code to Netlinx

playskool1

I sucked out the code from a functional system that currently has a Axcent 3 Pro Controller. The system will be upgrading their master controller to a NI-3100. Looking at the source code it looks very different the way I would write it for Netlinx. Things that I have noticed were: there were no Data_Events and I'm not sure what else but it looks confusing to me but may be easy for others. I was wondering if there is an easy way of doing this? I tried compiling the existing code set up for Netlinx and I already got 1 error. Any tips or tricks that I should know? I have no kind of experience with Axcess.

ryanww

Axcess is very different from what Netlinx has become. It is based on basically everything running on one loop of the processor on one pass. Netlinx on the other hand can handle events simultaneously as it is multithreaded. Now it does have a define_program section which acts the same way almost as axcess but I wouldn't recommend using it too much.

It probably won't be too terribly hard to port it over by hand, but there isn't an 'automatic' way of doing it. Basically devices on an axcess system only had a channel number and a device address between 1-254. ) was the processor. There was no system number since it was only one processor period. So for each device in the define_device section, you need to change it from a single axlink address number to be x:1:0 where x is the original number.

Pushes will have to be converted into button_events with push and release information in them for each button. Original button push statements were written like this: push[dev_num,channel]. Just re-write it with the proper button_event and it will be fine.

Now as far as how serial worked, axcess relied on creating buffers. You can keep that kinda if you want. But Netlinx data_events is now how you get the data from serial devices. You will most likely re-do how you parse the data and use it within your system either by adding modules or whatnot.

Hopefully this gave you a good starting ground on understanding how to read axcess. Its not that much different, but you can just over think on how it works. It is a seriously dummed down version of netlinx.

PhreaK

ryanww wrote: »

Netlinx on the other hand can handle events simultaneously as it is multithreaded. Now it does have a define_program section which acts the same way almost as axcess but I wouldn't recommend using it too much.

Since when is it multi-threded? Netlinx is event based but events are not executed simultaneously, instead they are passed into a processing cue and executed serially - which does make some of the data management a little easier but can be a pain in the arse for performance.

In regards to porting the code, depending on your time / budget constraints and how the code was originally written it may even be worth looking at a re-write. By all means you can port things across but as ryanww said AXCESS and NetLinx are two different languages and there are a few different ways of accomplishing things within NetLinx that are a hell of a lot more effecient and logical than AXCESS. It will also make modifications and future upgrades a lot easier.

chill

PhreaK wrote: »

In regards to porting the code, depending on your time / budget constraints and how the code was originally written it may even be worth looking at a re-write. By all means you can port things across but as ryanww said AXCESS and NetLinx are two different languages and there are a few different ways of accomplishing things within NetLinx that are a hell of a lot more effecient and logical than AXCESS. It will also make modifications and future upgrades a lot easier.

You shouldn't need to do any porting. NetLinx was specifically designed to be backwards-compatible with Axcess. You can do a 'compile as netlinx' on your axcess code and load it on the NL system, and it should build and run. You may have to change the device numbers to D:P:S notation, but I don't think even that is necessary.

That said, the NetLinx language has so much more capability than Axcess, it's not even funny. If there is any chance you'll ever have to look at this system again, and you have the time, I'd rewrite it as NetLinx. As Kim says, it will make future maintenance *much* easier.

Marc Scheibein

As long as you still work with AXlink devices, it is not required to change the device address to [noparse]number:port:system[/noparse] ([noparse]n:p:s[/noparse]). The master later will add port=1 and system="his local system number" to the existing device number (this also is a workaround to prevent the compiler to fail i.e. if a [noparse]n:p:s[/noparse] noted device is passed into an AXcess based call). Another way is to refer to <devicename>:number if working with [noparse]n:p:s[/noparse] (as long as the device is local).

The NetLinx compiler also is MUCH more accurate regarding syntax, because he has much more capabilities in coding. There are several situations where missing of wrong brackets work in AXcess, but in NetLinx the compile may fail or the code would not do the same like in AXcess previously.

You may also stumble over constant or variable names used in AXcess, which in NetLinx are keywords, like

DEFINE_CALL 'MY_CALL'(dev,parameter)
{
PULSE[dev,parameter]
}

This would compile in AXcess, but in NetLinx "dev" is a keyword and may fail

Another issue might be the serial port configuration. In AXcess, the SET BAUD commonly was done in DEFINE_START, but this may fail in NetLinx, because the master has past DEFINE_START before the device is online, and so the SET BAUD fails. So for this a DATA_EVENT should be created.

Thomas Hayes

To get the code to work shouldn't be that hard at all, I really doubt that you will need to do a re-write. I had over 100 Axcent-III's that I am changing to NI-3100's. A re-write will make your existing code run a lot better but there are only a few things that need to be changed for it to run for now. Device addressing is the big one. Changing the 'push' to 'button_event' and a few other small tweaks should have you up and going.

DHawthorne

chill wrote: »

You shouldn't need to do any porting. NetLinx was specifically designed to be backwards-compatible with Axcess. You can do a 'compile as netlinx' on your axcess code and load it on the NL system, and it should build and run. You may have to change the device numbers to D:P:S notation, but I don't think even that is necessary.

That said, the NetLinx language has so much more capability than Axcess, it's not even funny. If there is any chance you'll ever have to look at this system again, and you have the time, I'd rewrite it as NetLinx. As Kim says, it will make future maintenance *much* easier.

Device numbers do in fact need to be changed, it's not an option. As I recall, there are one or two other mandatory changes, but the compiler will flag them as soon as you try to compile it. I'd say its about 90% backwards compatible. However, it's also probably well worth your time to go through and convert things like PUSH statements to button events, that kind of thing.

LCubed@snet.net

it's also probably well worth your time to go through and convert things like PUSH statements to button events, that kind of thing.

Be careful when you do this because if a push event is handled within the DEFINE_EVENT section, it won't be handled in the DEFINE_PROGRAM section. For example, adding:

DEFINE_EVENT
Button_Event[TP,1]
{
  Push:
  {
    Will do something here
  }
}

Will keep this from working

DEFINE_PROGRAM
PUSH[TP,1]
{
  Won't do anything
}

Because the event was already handled in the DEFINE_EVENT section.

DHawthorne

Well, the idea was take it out of the PUSH statement altogether, and use a BUTTON_EVENT instead .

LCubed@snet.net

I know, but I've worked on some of that code before where there are a LOT of push statements, and if you're working on the translation in pieces and some push statements are duplicated to do other things somewhere else in the main program or in an include file, breakage could happen. So it's just good to know this could occur so you'll know what to look for if something suddenly stops working.