translate_device() is not a standard Netlinx function (unless it's some sort of DUET or VA thing) so I don't think anyone can tell you what it does without seeing the source code for the function.
Good question. I wish I had a good answer. I searched my hard drive and did find that Program Files\Common Files\AMXShare\Com\nlc.dll has the text "translate_device" inside the file but as far as I know that's not a function we have access to. Maybe someone else will have a better answer.
I think I seem to remember it's something to do with Duet. It's used for feedback and basically when you turn on a channel on in device 2 it really turns on the channel in device 1. Likewise when you get a push on device 1, it shows up as a push on device 2.
I think I seem to remember it's something to do with Duet. It's used for feedback and basically when you turn on a channel on in device 2 it really turns on the channel in device 1. Likewise when you get a push on device 1, it shows up as a push on device 2.
Something like a COMBINE then, without the intermediate virtual device?
Is translate_device a keyword in Duet? It doesn't seem to be in Netlinx.
Not too long ago there was a discussion about "redirect_string" which is supposed to make two devices echo all string info from each other. Supposedly it obviates the need to write string handlers to relay info between two devices (for example, when using a TCP/IP connection from a PC or RS232 to IP device) to program an XAP800 or Polycom conferencing mixer through the RS232 port).
I couldn't get it to work. Has anybody used redirect_string successfully? I had a discussion once with a very experienced AMX programmer who told me that, "of course, you can use redirect_string to do that," but I'm not sure whether he actually did it successfully or just surmised that it would work.
Redirect string has nothing to do with DUET. I think this has been used in the comm module for the old dms panels. Another virtual device was created in this module and the translate device command was used between the the virtual and the dynamic device.
I'm not expert in this stuff, but I've seen it before. If you grab the module for the Denon 5800 from the InConcert section, you'll find the 'comm' (Denon_AVR5800.axs) is actually editable.The top line is:
MODULE_NAME='Denon_AVR5800'(DEV port, DEV vRcvr)
a little later on we have:
DEFINE_DEVICE
vdRcvr = DYNAMIC_VIRTUAL_DEVICE
and a lttle later yet we have:
DEFINE_START
translate_device(vRcvr, vdRcvr)
and the vRcvr is never referenced again, it's all stuff like this:
// Automatically send some feedback on power up
send_string vdRcvr, "'POWER=', avrPowerState"
send_string vdRcvr, "'MUTE=', avrMuteState"
send_string vdRcvr, "'VOLUME=', itoa(avrVolume)"
which I believe is the module sending stuff back to the string event handlers. Is this enough context for someone to hazard an educated guess as to what is happening here?
Hard to explain what exactly it does except that it breaks feedback loops. If you've used any of that old Landmark gear on a Netlinx system, those modules all use it - its what creates all the mystery virtual devices..
I use it in a module that bridges device comm modules (iPorts more often than not), to the serial ports of Global Cache controllers through the virtual device of the Global Cache comm module
OK - trying to remember last sumer - Pgm III went over the translate_device(vdvMain,vdvModule) My notes are sketchy, but basically it can break the loop when you send a string or a command to a device in a module. It also allows you to turn a channel on in a device, and it will not show as on until it is turned on in the module.
Translate_device goes in the Start section of the module, and "connects" a virtual device defined in the module definition, and another virtual defice (vdvModule) Anything done to vdvMain will happen on the vdvModule.
Here is a quick demo that they did in class. Pulsing a channel on the main virtual device does not show the channel active (on the main virtual device) until it is turned on via the module device 2 seconds later.
MODULE_NAME='magic mod test' (dev vdvMain, dev dvDev)
(***********************************************************)
(***********************************************************)
DEFINE_DEVICE
vdvModule = dynamic_virtual_device
DEFINE_START
translate_device(vdvMain, vdvModule)
(***********************************************************)
(* THE EVENTS GO BELOW *)
(***********************************************************)
DEFINE_EVENT
channel_event[vdvModule,27]
{
on:
{
wait 20
{
off[vdvModule,28]
on[vdvModule,27]
}
}
}
channel_event[vdvModule,28]
{
on:
{
wait 20
{
off[vdvModule,27]
on[vdvModule,28]
}
}
}
(***********************************************************)
(* THE ACTUAL PROGRAM GOES BELOW *)
(***********************************************************)
DEFINE_PROGRAM
(***********************************************************)
(* END OF PROGRAM *)
(* DO NOT PUT ANY CODE BELOW THIS COMMENT *)
(***********************************************************)
I remember thinking - wow that is cool, when would I use that, and then forgetting all about it until reading this post.
Agreed. It has nothing to do with Duet and has been around much longer than Duet. It has always been built into the NetLinx programming language and came about as the result of modules and using virtual devices to communicate with them. It was a way to get around the echo effect that Jeff talked about. It is not documented anywhere I know of. In fact, for a long time AMX did not even want anyone to be aware of this (early paranoia I think).
Unless you are a very experienced programmer and truly understand the nuances of programming modules and the interaction of modules with virtual devices and the main NetLinx code you should avoid this.
Also, on the redirect command. This has nothing to do with modules or Duet. It is a command to redirect serial data coming in on a port to go out a different port. So if you redirect serial port 1 to serial port 2 then any input from serial port 1 not only goes up to your program in a data_event but also goes out the other serial port. An example of this might two devices from the same manufacturer which connect via serial. However, you also need to see that serial data. This is a way of sniffing on that port and still having the data show up on the other device.
There really is no harm in that command. It can't do anything wrong other than have more events show up. But once you go down that path it will open up all kinds of questions about the effects of the command and it does get complicated. However, I'm guessing there would lots of answers from the guys on this forum.
I'm pretty sure I tried REDIRECT_STRING with IP devices and it failed. I will give TRANSLATE_DEVICE a go.
I'm working on a module to get IP connections to largely self manage.
TRANSLATE_DEVICE didn't work quite how I thought it would
I string events weren't triggering right and the ONERROR event for the IP Port not being open when a string came through was also not triggered. Back to the drawing board!
From an old AMX document 'NetLinx Module Interface Specification'
4. The NetLinx module must create a dynamic virtual device (keyword DYNAMIC_VIRTUAL_DEVICE) and translate (keyword TRANSLATE_DEVICE) between it and the virtual device defined by the glue code as the interface device. This will remove echoes the glue code would normally see by sending commands to and affecting channels on the virtual device.
From an old AMX document 'NetLinx Module Interface Specification'
4. The NetLinx module must create a dynamic virtual device (keyword DYNAMIC_VIRTUAL_DEVICE) and translate (keyword TRANSLATE_DEVICE) between it and the virtual device defined by the glue code as the interface device. This will remove echoes the glue code would normally see by sending commands to and affecting channels on the virtual device.
Thank you, thank you, thank you, thank you... that is exactly what I needed for this.
TRANSLATE_DEVICE is awesome, I use it in every module I write. It allows you to send COMMANDS and STRINGS and Turn Channels ON and OFF inside a module with out retriggering the code inside the module. It makes writing modules easier and makes them much more functional. I write the UI into all of my comm modules, it makes it very easy to implement control of a device in the Main program.
TRANSLATE_DEVICE is awesome, I use it in every module I write. It allows you to send COMMANDS and STRINGS and Turn Channels ON and OFF inside a module with out retriggering the code inside the module.
By this you mean that you can do this in a module:
This would get rid of the echo that occurs when updating a virtual's level in a module that has events listening on the same channel. That would be very useful.
Paul
This would get rid of the echo that occurs when updating a virtual's level in a module that has events listening on the same channel. That would be very useful.
Paul
Check out the release notes in the AMX-PI for Duet firmware build 316 (v3.00.316). "Module Virtual Devices". It's also listed (but not explained) on page 76 of the Visual Architect manual. Seems likes essentially the same thing.
Yuriy
Posts: 20
Comments
PROGRAM_NAME='test'
DEFINE_DEVICE
vdvDev1 = 33001:1:0
vdvDev2 = 33002:1:0
DEFINE_START
translate_device(vdvDev1, vdvDev2)
DEFINE_EVENT
DEFINE_PROGRAM
Is translate_device a keyword in Duet? It doesn't seem to be in Netlinx.
Not too long ago there was a discussion about "redirect_string" which is supposed to make two devices echo all string info from each other. Supposedly it obviates the need to write string handlers to relay info between two devices (for example, when using a TCP/IP connection from a PC or RS232 to IP device) to program an XAP800 or Polycom conferencing mixer through the RS232 port).
I couldn't get it to work. Has anybody used redirect_string successfully? I had a discussion once with a very experienced AMX programmer who told me that, "of course, you can use redirect_string to do that," but I'm not sure whether he actually did it successfully or just surmised that it would work.
DEFINE_DEVICE vdRcvr = DYNAMIC_VIRTUAL_DEVICEand a lttle later yet we have:DEFINE_START translate_device(vRcvr, vdRcvr)and the vRcvr is never referenced again, it's all stuff like this:// Automatically send some feedback on power up send_string vdRcvr, "'POWER=', avrPowerState" send_string vdRcvr, "'MUTE=', avrMuteState" send_string vdRcvr, "'VOLUME=', itoa(avrVolume)"which I believe is the module sending stuff back to the string event handlers. Is this enough context for someone to hazard an educated guess as to what is happening here?regards,
Bob Moyle
I use it in a module that bridges device comm modules (iPorts more often than not), to the serial ports of Global Cache controllers through the virtual device of the Global Cache comm module
Translate_device goes in the Start section of the module, and "connects" a virtual device defined in the module definition, and another virtual defice (vdvModule) Anything done to vdvMain will happen on the vdvModule.
Here is a quick demo that they did in class. Pulsing a channel on the main virtual device does not show the channel active (on the main virtual device) until it is turned on via the module device 2 seconds later.
MODULE_NAME='magic mod test' (dev vdvMain, dev dvDev) (***********************************************************) (***********************************************************) DEFINE_DEVICE vdvModule = dynamic_virtual_device DEFINE_START translate_device(vdvMain, vdvModule) (***********************************************************) (* THE EVENTS GO BELOW *) (***********************************************************) DEFINE_EVENT channel_event[vdvModule,27] { on: { wait 20 { off[vdvModule,28] on[vdvModule,27] } } } channel_event[vdvModule,28] { on: { wait 20 { off[vdvModule,27] on[vdvModule,28] } } } (***********************************************************) (* THE ACTUAL PROGRAM GOES BELOW *) (***********************************************************) DEFINE_PROGRAM (***********************************************************) (* END OF PROGRAM *) (* DO NOT PUT ANY CODE BELOW THIS COMMENT *) (***********************************************************)I remember thinking - wow that is cool, when would I use that, and then forgetting all about it until reading this post.
Translate_Device has nothing to do with DUET. It was created for early AMX programmed modules.
In short, links the two virtual devices together allowing for them to act as one, stopping the "ECHO" effect of send_command and send_strings.
There is alot of caveots when it comes to using this keyword, I would stay away from it unless you completely understand its use and actions.
But the quick down and dirty explaination. "Twisted Voodoo Dolls!".
It really is too bad [img][/img] is disabled...
Agreed. It has nothing to do with Duet and has been around much longer than Duet. It has always been built into the NetLinx programming language and came about as the result of modules and using virtual devices to communicate with them. It was a way to get around the echo effect that Jeff talked about. It is not documented anywhere I know of. In fact, for a long time AMX did not even want anyone to be aware of this (early paranoia I think).
Unless you are a very experienced programmer and truly understand the nuances of programming modules and the interaction of modules with virtual devices and the main NetLinx code you should avoid this.
Also, on the redirect command. This has nothing to do with modules or Duet. It is a command to redirect serial data coming in on a port to go out a different port. So if you redirect serial port 1 to serial port 2 then any input from serial port 1 not only goes up to your program in a data_event but also goes out the other serial port. An example of this might two devices from the same manufacturer which connect via serial. However, you also need to see that serial data. This is a way of sniffing on that port and still having the data show up on the other device.
There really is no harm in that command. It can't do anything wrong other than have more events show up. But once you go down that path it will open up all kinds of questions about the effects of the command and it does get complicated. However, I'm guessing there would lots of answers from the guys on this forum.
It now works like this...
this was the wonderful outcome of the 2009 Gator Bowl.
I'm working on a module to get IP connections to largely self manage.
I string events weren't triggering right and the ONERROR event for the IP Port not being open when a string came through was also not triggered. Back to the drawing board!
Care sharing that document (or where I can find it)? I don't think I've ever come across it...
No worries mate!
I never thought I'd see the day that I would be able to help Phreak!
P.S. Don't forget this is not supported (anymore?).
Neither is wrapping a NetLinx module inside a Duet module
Not supported is just another way of saying fun to implement.
DEFINE_EVENT BUTTON_EVENT [dvTouch_Panel, 0] { PUSH: { TO [vdvModule, Button.Input.Channel] } } DEFINE_PROGRAM Wait 2 { FOR (nFeedback_Channel = 1; nFeedback_Channel <= 255; nFeedback_Channel++) { [dvTouch_Panel, nFeedback_Channel] = [vdvModule, nFeedback_Channel] } }By this you mean that you can do this in a module:
// inside module A
send_level vdvDev, 1, 50
and not trigger this event:
// inside module A
level_event[vdvDev, 1]
{
send_string dvDev, "'VOL=', itoa(level.value)"
}
while still triggering:
// inside main code
level_event[vdvDev, 1]
{
send_level dvTP, 1, itoa(level.value)"
}
in the main code?
This would get rid of the echo that occurs when updating a virtual's level in a module that has events listening on the same channel. That would be very useful.
Paul
That's exactly what it does.
Check out the release notes in the AMX-PI for Duet firmware build 316 (v3.00.316). "Module Virtual Devices". It's also listed (but not explained) on page 76 of the Visual Architect manual. Seems likes essentially the same thing.