TCL scripts with multiple RepeaterLogics

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

TCL scripts with multiple RepeaterLogics

Rob Janssen
Anyone here who has experience with running more than one RepeaterLogic in a single Svxlink instance,
and using the TCL event scripts?

I am trying to configure our repeater with an extra RepeaterLogic operating under different callsign, and
linked to the main RepeaterLogic.  The audio on the second logic is just copied from the first.  It should
mostly do the same thing as the main logic except it sends a different callsign where appropriate.

The first thing that confused me is that the namespace of the RepeaterLogic is not always "RepeaterLogic"
but it is the actual name of that logic.   So we have two different namespaces for RepeaterLogic.tcl.
When the is file is not copied to a second file with "namespace RepeaterLogic2" in the heading, the
TCL functions for RepeaterLogic2 are not found.   Is this intentional?

It is more surprising because the same thing does not happen to the TCL functions for Logic.  Both
RepeaterLogics are calling functions from "namespace Logic".   The $callsign variable is different when
running the functions, so it is possible to select behaviour based on this.   Why is the same thing not
done with RepeaterLogic?

However, it appears that although the two Logic functions are in the same namespace, they still are a
different instance.   It appears that global variables in the Logic.tcl that are used e.g. to control the
ident and in our case the rgr_sound are different for both instances.  But as the instances have the
same name, how can we still access variables (like sql_rx_id) from another Logic?  Is this possible?

Rob

------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
_______________________________________________
Svxlink-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/svxlink-devel
Reply | Threaded
Open this post in threaded view
|

Re: TCL scripts with multiple RepeaterLogics

Eric -

Call file repeater1Logic.tcl and another repeater2Logic.tcl firts Line in tcl you need change too for repeater1 and repeater2 finally in .conf call repeater1 and repeater2


Le lun. 30 mai 2016 12:49 PM, Rob Janssen <[hidden email]> a écrit :
Anyone here who has experience with running more than one RepeaterLogic in a single Svxlink instance,
and using the TCL event scripts?

I am trying to configure our repeater with an extra RepeaterLogic operating under different callsign, and
linked to the main RepeaterLogic.  The audio on the second logic is just copied from the first.  It should
mostly do the same thing as the main logic except it sends a different callsign where appropriate.

The first thing that confused me is that the namespace of the RepeaterLogic is not always "RepeaterLogic"
but it is the actual name of that logic.   So we have two different namespaces for RepeaterLogic.tcl.
When the is file is not copied to a second file with "namespace RepeaterLogic2" in the heading, the
TCL functions for RepeaterLogic2 are not found.   Is this intentional?

It is more surprising because the same thing does not happen to the TCL functions for Logic.  Both
RepeaterLogics are calling functions from "namespace Logic".   The $callsign variable is different when
running the functions, so it is possible to select behaviour based on this.   Why is the same thing not
done with RepeaterLogic?

However, it appears that although the two Logic functions are in the same namespace, they still are a
different instance.   It appears that global variables in the Logic.tcl that are used e.g. to control the
ident and in our case the rgr_sound are different for both instances.  But as the instances have the
same name, how can we still access variables (like sql_rx_id) from another Logic?  Is this possible?

Rob

------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
_______________________________________________
Svxlink-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/svxlink-devel

------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
_______________________________________________
Svxlink-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/svxlink-devel
Reply | Threaded
Open this post in threaded view
|

Re: TCL scripts with multiple RepeaterLogics

Rob Janssen
Eric - wrote:
>
> Call file repeater1Logic.tcl and another repeater2Logic.tcl firts Line in tcl you need change too for repeater1 and repeater2 finally in .conf call repeater1 and repeater2
>
>

Thanks, I have found how to work around the problem but I am looking for the best method to manage the
files and to access data from another logic.   Having a copy of a file and changes to be made in 2 places is
not the best thing.  Fortunately most of our customizations are in Logic.tcl which is shared.

Rob

------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
_______________________________________________
Svxlink-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/svxlink-devel