Home AMX User Forum NetLinx Studio

FIRST_LOCAL_PORT

Hi all,
I've the following problem:

DEFINE_DEVICE
TP = 10128:1:0
WEB_TUNER_RS = 225:1:0
dvFirstIP = 0:FIRST_LOCAL_PORT:0
dvSecondIP = 0:FIRST_LOCAL_PORT+1:0

at compiling time I've the following error:

Starting NetLinx Compile - Version[2.5.2.20] [05-27-2010 15:21:35]
C:\Documents and Settings\braca\Desktop\AMX-develop\amx-project\main.axs
ERROR: (0): C10580: Internal Error: Major system error occurred during code generation
C:\Documents and Settings\braca\Desktop\AMX-develop\amx-project\main.axs - 1 error(s), 0 warning(s)
NetLinx Compile Complete [05-27-2010 15:21:35]

If I change the dvSecondIP declaration in the following way:
dvSecondIP = 0:3:0

I don't have any problem.
Could someone suggest me anythings or where I wrong?
Thanks in advance for your responce.
Best regards
ND

Comments

  • Jorde_VJorde_V Posts: 393
    Don't use first_local_port. It's actually a set value and not the first_local_port at all. (Hence the conflict)

    Also I don't think you can add/substract in the device address.
  • truetrue Posts: 307
    You can do math in the different components of a dev.

    You can't do this assignment in a define_device, however. You can do it in a define_variable, and in code followed by a rebuild_event().
  • Thanks for your answer.
    Can you send me some link or reference about some useful tutorial or manuals to improve my amx programming skills?
  • ThorleifurThorleifur Posts: 58
    I beg to differ..

    You can use 0:FIRST_LOCAL_PORT+x:0 in define device.
    dvDEVICE = 0:FIRST_LOCAL_PORT+3:0
    
    // BUT HEREAFTER ONE MUST USE 0:dvDEVICE.PORT:0 WHEN "USING" DEVICE
    
    DATA_EVENT [0:dvDEVICE.PORT:0]
    {
         // DO SOMETHING
    }
    
    SEND_STRING 0:dvDEVICE.PORT:0,"'DO SOMETHING'"
    

    But if you make a mistake like DATA_EVENT [dvDEVICE] it will not compile and give you a major system error. Had some experience with that and lost alot of time to finding those faults.

    I don?t know about any tutorials about programming. The AMX programming classes are good for you. That and grinding the Programming Guide and of course this forum.
  • yep
    thanks
  • DHawthorneDHawthorne Posts: 4,584
    I just don't use FIRST_LOCAL_PORT. At first blush, it seems like a handy shortcut to keep ports from being duplicated, but then I realized if I use something like "0:FIRST_LOCAL_PORT+1:0," then the next time use "0:FIRST_LOCAL_PORT+2:0," I still have to keep track of how many times I've incremented it and were. If I am going to have to do that, why not make it explicit in the first place? That also gives the advantage of knowing exactly what the value is when debugging.

    The other problem is that a lot of third-party module writers are using FIRST_LOCAL_PORT, and some of them are burying in includes or files you might not be looking at. So you still have to root through everything to find out what ports are actually in use, then change them as needed. The bottom line is, it's simply not very useful.
  • a_riot42a_riot42 Posts: 1,624
    First_local_port is a constant set to 2 so it isn't really that useful for anything other than making sure you don't assign a port to 0:1:0. I just hard code all IP ports. When Netlinx gets pushed into the 21 century we might see some more valuable IP stuff.
    Paul
  • a_riot42 wrote: »
    When Netlinx gets pushed into the 21 century we might see some more valuable IP stuff.
    Paul
    It's now nearly 13 years into the 21st century...
  • HedbergHedberg Posts: 671
    Thanks for your answer.
    Can you send me some link or reference about some useful tutorial or manuals to improve my amx programming skills?

    Tech note #407 has some useful info including some things about ip clients and servers. See also tech note #937 for more info. Note that these references do not always agree -- see how they differ about how to wrte the data event:

    407 says you must do like:
    DEFINE_EVENT
    DATA_EVENT[0:dvPcom.PORT:0] // NOTE: Can’t use [dvPcom] here!
    {
    ONLINE :
    {
    }
    }
    

    but 937 says:
    DATA_EVENT
    
     
    
    DATA_EVENT [dvIPDevice]
    
                            {
    
                            String:
    
                                        {
    
                                        Parse String here
    
                                        }
    
                            }
    

    also interesting is that it appears that first_local_port is a constant 2 but tn#937 says you should start with port 4:

    "a. It’s usually best to use the lowest port possible above 0:3:0 – start with 0:4:0 or above"

    I've also seen references which say to start with port 5, I don't know why.
  • ericmedleyericmedley Posts: 4,177
    a_riot42 wrote: »
    First_local_port is a constant set to 2 so it isn't really that useful for anything other than making sure you don't assign a port to 0:1:0. I just hard code all IP ports. When Netlinx gets pushed into the 21 century we might see some more valuable IP stuff.
    Paul
    Agreed. I've alway felt it was a badly labelled thing.

    It looks like, 'Oh hi! I'm keeping track of all the local ports being defined and here's the next open port.'. But it's really just, 'oh crap. What's the first local port I can use again? 2 or 3? I can't remember. Oh yeah! It's 2.'
  • Still being schooled!

    After 4 years experience of some pretty weird and wonderful control situations involving AMX I thought I would be past getting completely schooled by Netlinx

    I have just lost an hour trying to fault fing the Major System Error only to then read this post and learn about the FIRST_LOCAL_PORT and how it doesn't actually do what its title would suggest.

    From here on in its a "hard wired" IP port for me.

    Just glad someone else has experienced this and I haven't lost days over it.

    Hats off to the forum and all the regular contributors for making life easier for others.
  • GregGGregG Posts: 251
    It would be nice to have something like:

    NEXT_UNUSED_LOCAL_PORT

    instead.
  • ericmedleyericmedley Posts: 4,177
    GregG wrote: »
    It would be nice to have something like:

    NEXT_UNUSED_LOCAL_PORT

    instead.

    It could be a compiler directive. #NEXT_UNUSED_LOCAL_PORT
  • GregGGregG Posts: 251
    ericmedley wrote: »
    It could be a compiler directive. #NEXT_UNUSED_LOCAL_PORT

    That would actually be more appropriate, since it really only needs to resolve at compile time.
  • a_riot42a_riot42 Posts: 1,624
    GregG wrote: »
    That would actually be more appropriate, since it really only needs to resolve at compile time.

    Why not a #NEXT_UNUSED_AXLINK_DEVICE, #NEXT_UNUSED_DUET_DEVICE, #NEXT_UNUSED_VIRTUAL_DEVICE, etc as well?

    Personally I prefer to be able to see the numbers myself. If you want this kind of thing you can certainly write a script to do this for you.
    Paul
  • ericmedleyericmedley Posts: 4,177
    a_riot42 wrote: »
    Why not a #NEXT_UNUSED_AXLINK_DEVICE, #NEXT_UNUSED_DUET_DEVICE, #NEXT_UNUSED_VIRTUAL_DEVICE, etc as well?

    Personally I prefer to be able to see the numbers myself. If you want this kind of thing you can certainly write a script to do this for you.
    Paul

    Yeah, I agree. I'd rather just declare them myself too. But I can see how it would make cookie cutter colde go a lot quicker.
  • I'm lost in the new website. Where to access tech note 407 or 937? Or any tech note?

  • Tech notes have not been ported over to the new website yet.
    Here are some links for 407 and 937 - these are on my Dropbox so no guarantee they will be there forever.
    https://dropbox.com/s/zi2hgkbn45161vv/tn407-NetLinx%20Programming%20Conventions.pdf?dl=0
    https://dropbox.com/s/3kvmzlwgc2vcz1d/tn937-IP%20Connections%20Demystified.pdf?dl=0

  • Thanks a lot!

Sign In or Register to comment.