Medialon MxMs' Help 
  
Name: Medialon Low Level Communicator
Version: 1.2.1
Available for: Manager V5 (all versions), Showmaster (ST & Pro)
Limitation In:  
Device Brand: Medialon
Positrack Compatible: Partially
Resources type: Serial, MIDI or TCP/IP - UDP/IP Network
 
Compatible hardware interfaces - available resource modules (MRC):
 

 

> Overview | > Installation (MXM) | > Creation (Device) | > Commands (List Of) | > Variables (List Of) | > Support


Overview :

The Low Level Communicator MxM is a low level but powerful MxM.

It is a low-level MxM because it is not dedicated to a special device and is able to use many raw communication protocols.

But it is powerful for two reasons.

Five types of communication available
- Serial
- TCP/IP Client
- TCP/IP Server
- UDP/IP Client-Server
- MIDI

Writing of customized drivers
The
programmer can write its own set of commands, create monitoring variables linked to the reception of specified frames, and much more, in order to write drivers dedicated to specified devices and projects

Note: When this MXM is used with Showmaster and when a TCP/IP server device is used, the external connection needs to be setup to address Medialon Showmaster Editor host during the programming process. When a programming process is done, the external connection can be setup again to address Showmaster.

 

> Top


Installation (MXM):

No specific installation is required.

> Top


Creation (Device):

At the creation of the device, a setup dialog with seven main pages box pops-up.
These seven main pages are: Type, Frames, Checksum, Commands, Answers, Monitoring, Automation.

All these parameters are saved with the Manager project, as all other MXMs, but they also can be saved in separate drivers files. These drivers files can be re-used in other projects ( see DRIVERS section).

TYPE:
Five type of communication are available: serial, TCP/IP client, TCP/IP server, UDP/IP Client-Server, MIDI, which correspond to five different parameters pages ( TCP/Server is not available in lite version ):

Serial parameters:



COM Port:
The number of the com port to use with this device. If this port is used by another device, the name of the device is written between brackets within the number of the port. If a message says "Impossible to open this port" at the time you close the dialog box or at the startup of the device, it may be because this port has been opened by another application or driver.

BaudRate, Stop bits, Data bits, Parity:
The setup at which the port must run at the startup of the device.

DTR, RTS:
These two signals are present in the RS socket. In some protocol, these signals are used to detect the start of a frame, or to say if the device can send or receive.

Full Duplex / Half Duplex:
Full duplex is used with separate lines for sending and receiving.
Half duplex is when the same line is used alternatively for both.

Break character:
Break character is the character that will be set in the frame for sending a break (low status) on the serial line.

Break time:
The break time is the time that this break will last.


TCP/IP Client parameters



Address:
Address of the server on which this client will connect..

Port:
Port on which this client will connect.

Auto reconnection:
When this option is checked, the MxM will periodically try to reconnect if it looses the connection.

Optimize small packets:
Check this option if you send small frames and if you want to increase the speed of the transmiting.
It will set the TCP_NODELAY option in the Network system. Enabling the TCP_NODELAY option disables the TCP Nagle Algorithm (and vice versa). The Nagle algorithm (described in RFC 896) is very effective in reducing the number of small packets sent by a host by essentially buffering send data if there is unacknowledged data already "in flight" or until a full-size packet can be sent.
However, for some applications this algorithm can impede performance, and TCP_NODELAY can be used to turn it off. These are applications where many small messages are sent.
Application writers should not set TCP_NODELAY unless the impact of doing so is well-understood and desired, since setting TCP_NODELAY can have a significant negative impact of network and application performance.


TCP/IP Server parameters ( TCP/Server is not available in lite version )



Port:
Port on which this server will listen.

Adapter for reception:
If "all"is checked, the server will listen on all the network adapters present on the computer, if not, it will listen on the specified adapter.

Optimize small packets:
Check this option if you send small frames and if you want to increase the speed of the transmiting.
It will set the TCP_NODELAY option in the Network system. Enabling the TCP_NODELAY option disables the TCP Nagle Algorithm (and vice versa). The Nagle algorithm (described in RFC 896) is very effective in reducing the number of small packets sent by a host by essentially buffering send data if there is unacknowledged data already "in flight" or until a full-size packet can be sent.
However, for some applications this algorithm can impede performance, and TCP_NODELAY can be used to turn it off. These are applications where many small messages are sent.
Application writers should not set TCP_NODELAY unless the impact of doing so is well-understood and desired, since setting TCP_NODELAY can have a significant negative impact of network and application performance.


UDP/IP parameters



Maximum input packet size:
This setting is low by default in order to minimize resources usage. It can however be raised in order to receive bigger UDP frames, up to a maximum of approximatively 64KB. All frames above this size will be truncated when received.

Adapter for reception:
If "all"is checked, the MXM will listen on all the network adapters present on the computer, if not, it will listen on the specified adapter.

Port:
Port on which the MXM will listen.

Exclusive port:
If checked, the port will not be shared, no other application can simunalteneously open it on the same computer.

Multicast:
Check this option if you want to specify a multicast address for listening. (It is the responsibility of IANA to manage the multicast address space [27, 1]. Multicast addresses range from 224.0.0.0 through 239.255.255.255. The address 224.0.0.0 cannot be assigned to any group since it is reserved. These addresses are permanent in the sense that it is the address, not the membership of the group, which always exists [15]. A permanent group may have any number of members at any time, which can be even zero. Other multicast addresses are temporary in nature and the groups which they represent are called transient multicast groups).

Default Destination Parameters:
This is where you can specify a default address and a default port where udp frames will be sent by the monitoring process( see the creation of monitoring parameters ), and by the "Send Frame" command.


MIDI parameters



Output port:
Port on which the MXM will send MIDI frames.

Output port:
Port on which the MXM will receive MIDI frames.

FRAMES :



Output :
Parameters used in the format of the output frames.

Checksum character:
Checksum character is the character that represents the checksum in the frame and it will be computed before sending the frame.

Hexadecimal character:
This is the ascii character used for sending an hexadecimal character. For example, if the "!" is used, you can write !0A!0D for sending a carriage return and a line feed.

Decimal character:
This is the ascii character used for sending a decimal character. For example, if the "&" is used, you can write &255 for sending this upper ascii byte.

Input:
These parameters define the validity of an input frame. This validity is the one taken into consideration for the device variable FramesCount (see below) to indicate that valid frames have been incoming.

Count of bytes:
This is the count of bytes that the device waits for. If ending or header character are filled (see below), this parameter can be null: in this case all the bytes between ending character and(or) header character fills the frame.

Timeout:
This is the maximum time that can occur between two bytes of a same frame. Each time this value is over, the device empties its internal counter and waits for the first byte of a frame. If this value is set to zero, the mechanism is disabled. WARNING: if the timeout is set to zero and the count of input bytes is also set to zero, the input frame can become huge if it is not read out by "Get frame".

Header character:
When this character is received, it is considered to be the first character of a frame. You can use the hexadecimal character here (for example !02).

Ending character:
When this character is received, it is considered to be the last character of a frame. You can use the hexadecimal character here (for example !03).

Perform checksum verification:
If this option is enabled, the checksum is calculated each time a frame is considered to be valid by the previous parameters. The byte of the checksum must be equal to the checksum byte before a frame is considered to be definitly valid.

Convert only the non-literal bytes to the hexadecimal format:
If a non literal byte (ascii value >31 and <127) is received it is converted to the hexadecimel format, using the "hexadecimal character" entered before.

Convert all the bytes received to the hexadecimal format:
All the bytes received are converted to the hexadecimel format, using the "hexadecimal character" entered before.

Keep the original values:
When checked, nothing is converted.

Store frames:
When checked, all the frames received are stored and you can fetch them with the "Get frame" command. When unchecked, only the last frame is stored.

Character replacement:
This section lists the character that must be replaced in the frames before sending and replaced back the other way upon reception.

Excluded/Replaced:
The left list contains the excluded characters, the right list contains their replacement. On output excluded characters are replaced by the corresponding string, and on input the replacement string is transformed back to the original characters.

Not for header/ending character:
Check this box if you don't want to aply the replacement to the firt and to the last character of the frame.

Checksum before replacement:
Tells if the checksum (if enabled) must be calculated before or after the character replacement phase. If the checksum occurs before the replacement, then it is computed on the original string and if the checksum value happens to fall on a special character, it will also be replaced. If the checksum occurs after replacement, it is computed on the replaced string, and the checksum value itself is not replaced if falling on a special character.


CHECKSUM



These parameters define the checksum verification options. They work together with the "checksum character" and "checksum before replacement" options of the "Frames" config tab.

Checksum check can be enabled on input or output frames, or on both. The first occurrence of the "checksum character" will be replaced upon sending or reception by the appropriate checksum, computed using the following options:

Checksum Type:
This allows to select the type of checksum of the frame:

Sum
This checksum is the sum of all the bytes between the byte indicated by 'Start from byte' parameter and the byte before the checksum character or indicated by 'Stop at byte' parameter.
Note: 'Checksum pos' parameter is not used.

Xor
This checksum is the result of a XOR operation of all the bytes between the byte indicated by 'Start from byte' parameter and the byte before the checksum character or indicated by 'Stop at byte' parameter.
Note: 'Checksum pos' parameter is not used.
Note: 'Count of Bytes' parameter is always 1 with this type.

Or
This checksum is the result of a OR operation of all the bytes between the byte indicated by 'Start from byte' parameter and the byte before the checksum character or indicated by 'Stop at byte' parameter.
Note: 'Checksum pos' parameter is not used.
Note: 'Count of Bytes' parameter is always 1 with this type.
Note: This is a very inefficient checksum but it is present in some protocols.

Crc16
This checksum is the two bytes result of a polynomial calculation between the byte indicated by 'Start from byte' parameter and the byte before the checksum character or indicated by 'Stop at byte' parameter.
Note: CRC stands for Cyclic Redundency Check).
Note: See 'Crc 16 mask' parameter definition for more details.
Note: See 'Crc 16 initial value' parameter definition for more details.
Note: 'Checksum pos' parameter is not used.

Level Control System 7 Bit Checksum
This type of checksum is used by the Level System Control Matrix3/Matrix4 protocol.

Alcorn Mc Bride AMINet
This type of checksum is used by the Alcorn Mc Bride AMINet UDP protocol (for the DVM4).

Start checksum from byte (from start)
It indicates at which byte of the frame the checksum computation must start (zero indexed). If this value is not set, the computation starts from the first byte.

Stop checksum at byte (from end)
It indicates at which byte of the frame the checksum computation must stop (zero indexed). If this value is not set, the computation stops just before the checksum byte.

Checksum pos
It indicates at which byte of the frame the checksum byte is located (zero indexed).

Crc16 mask
This parameter indicates which members of the polynome are used to compute the CRC. Each bit corresponds to a member of the polynome:

- A001h (default value) which is commonly used in the industry indicates the polynome: x^15 + x^13 + x^0.
- The CCITT defines the value 1021h which indicates the polynome: x^12 + x^5 + x^0.
- Any other value can be used accordingly to the device protocol definition. Please refer to the device protocol documentation.

Crc16 initial value
This parameter indicates a constant value used to initialize the computation registers:

- 0000h (default value) is commonly used in the industry.
- The CCITT defines the value FFFFh.
- Any other value can be used accordingly to the device protocol definition. Please refer to the device protocol documentation.

High byte first
When checked the order of the two bytes resulting of the Crc16 is high-low, when not checked it is low-high.

Two's complement
A (NOT+1) operation is performed on the checksum byte. ( also explained as 256 minus the value ).

ASCII coded
The result of the operation is changed into ASCII characters.
Important note: if the size of the checksum is set to 1, the "ASCII coded" operation will create two bytes, if the size of the checksum is set to 2, the "ASCII coded" operation will create four bytes.
For example, with a size of 1 and a checksum result of 110 (in decimal) the two bytes will be the ASCII character "6" and "E".

Count of bytes
The count of bytes of the checksum: it is usually 2 for the CRC16 checksum and 1 for the others.



COMMANDS

The commands created in this section are added to the device command set.
These commands can contain parameters where variables can be used.

Important Note: the name of a command fully identifies the command, thus renaming a command must be processed with care. As an example: if the "Play" command of a command driver is used by cues of several Low Level Communicator devices, renaming the command to "Play2" will update the cues of the currently edited device. However cues of the other devices will not be updated if the driver is loaded into these devices.

Each command can belong to positrack groups. This positrack mode is very useful when programming a timeline. If several commands belonging to the same positrack group are used in a timeline that is put in pause mode, only the last command placed before the pause point is executed.



  • User commands: the list of commands created.
  • Positrack groups: the list of all the groups created.
  • Inside this group: the list of commands that belong to the group selected.
  • Not inside this group: the list of commands that do not belong to the group selected.

When you create a new command, tou can specify the name and the output frame of this command.
In the output frame, it is possible to define parameters, that will appear afterwards in the "Send User Command" command.



In the frame, the syntax of the parameters are between brackets.
It contains the name, the type, and the size of the parameter.
Five types of parameters can be specified: integer, string, time, date and enum; it will be the type of the parameters that will appear in the command cue.
Six modes of conversion can be specified:
  • hexa: the bytes will be the ascii representation of the hexadecimal value of the parameter.
  • decimal: the bytes will be the ascii representation of the decimal value of the parameter.
  • bcd: the bytes will be the ascii representation of the bibary-coded-decimal value of the parameter.
  • low-high: the bytes will be the binary value of the parameter, with the low byte first.
  • high-low: the bytes will be the binary value of the parameter, with the high byte first.
  • literal:: the bytes will be the string value of the parameter.
The size represents the minimum count of bytes that will be sent: if the result of the conversion has only one byte, zero is added first.

The enum type is different than the other because for each item of the enum, you can specify tha name and the value to be sent:



In the example above, a Power command has an enum parameter called POWER that can have 2 values: OFF and ON. When ON will be selected in the cue, the value !01!10 will be inserted in the frame. When OFF will be selected in the cue, the value !02!20 will be inserted in the frame.


ANSWERS



This page let you enter specific answers to frames received.
If "For each valid frame received, answer:" is checked and if a frame is specified, this frame will be sent each time any valid frame is received by this device.
if "When receiving this valid frame" is checked, you can specify a list of answers corresponding to a list of specific valid frames received.

MONITORING

In this page, you can specify a list of frames that will be periodically sent.



- Fixed Length Character: character used in variable definition to specify a fixed length unknown character (default is 'X').
- Variable Length Character: character used in variable definition to specify a variable length character string (default is '?').

- Period:The period if the time in tenth of seconds at which the selected request is sent. Each request can have a different period.
- Wait & timeout: If the "Wait for answer"
is checked, the device will wait from an answer before another request is sent. If the answer is not received within the time specified in the "Timeout" parameter, the next request is sent.

You can also create monitor variables.
These variables will appear in the Variables Inspector of Manager and will be automatically updated each thier corresponding frame is received.

- Linked: A request can be linked to a monitoring variable. It means that the frame containing the variable will be considered as valid only if the linked request has been sent just before. If the protocol that you use does not send the same answer format for several monitoring variables, you don't need to use the "link" mode.

- Disable request frames: This is useful when you are in test phase: it disables the periodic sending of the request frames.



After entering the name and the type of variable, enter the waited frame.
Use the fixed length character (default is 'X') to specify undefined characters.
Use the variable length character (default is '?') to specify a undefined string of character.

To determinate the position and the length of the bytes to be monitored in the variable, select these bytes in the frame before closing the dialog box.

- Type: The types can be: integer, string, time, date or enum.
When the type is integer or time, the variable is updated with the binary value of the bytes received.
When the type is string or date, the variable is updated with the literal value of the bytes received.

If the selected type is Enum the dialog box shows an enum editor which allows to define the Enum.

- Format:

  • hexa ascci value: the bytes received are the ascii representation of the hexadecimal value.
  • decimal ascii value: the bytes received are the ascii representation of the decimal value.
  • bcd value: the bytes received are the binary coded decimal representation of the value.
  • low-high bytes: the bytes received are binary bytes,with low byte first.
  • high-low bytes: the bytes received are binary bytes, with high byte first.

- Update Mode:

  • Immediate: The variable is updated when the frame is received regardeless if the 'Store Frame' option is checked.

  • On 'Get last frame' Command: The variable is updated when the frame is read with the command 'Get last frame'. If there are some other frames already stored in the input buffer, those frames must be read before the variable could be updated.

Note: if the option 'Store Frames' is not checked in the Frames tab, this option has no effect and the default 'Immediate' mode is used.
Note: when the value type is 'Integer', it is possible to display the value in decimal or integer format in the dialog box that opens when editing the value.

Examples:

  • if the variable type is integer with format "high-low bytes" and the frame specified is VALUE=X (where X is selected) and the frame received if VALUE=!02, the value of the integer variable will be 2.

  • if the variable type is integer with format "high-low bytes" and the frame specified is VALUE=XX (where XX is selected) and the frame received if VALUE=!01!02, the value of the integer variable will be 258 ( 102 in hexadecimal).

  • if the variable type is string with format "high-low bytes" and the frame specified is VALUE=X (where X is selected) and the frame received if VALUE=2, the value of the string variable will be "2".

  • if the variable type is string with format "high-low bytes" and the frame specified is VALUE=X (where X is selected) and the frame received if VALUE=!02, the value of the string variable will not be a displayable character because !02 is not a valid ASCII character.

  • if the variable type is integer with format "high-low bytes" and the frame specified is VALUE=X (where X is selected) and the frame received if VALUE=2, the value of the integer variable will be 50 ( 50 is the decimal ASCII value of "2", 50=32 in hexadecimal ).

  • if the variable type is integer with format "high-low bytes" and the frame specified is VALUE=XX (where XX is selected) and the frame received if VALUE=12, the value of the integer variable will be 12594 ( 3132 in hexadecimal, where 31 is the hexadecimal ASCII value of "1", and 32 is the hexadecimal ASCII value of "2").

  • if the variable type is integer with format "bcd value " and the frame specified is VALUE=XX (where XX is selected) and the frame received if VALUE=!01!23, the value of the integer variable will be 123.

  • if the variable type is integer with format "hexa ascii value " and the frame specified is VALUE=X (where X is selected) and the frame received if VALUE=A, the value of the integer variable will be 10.

  • if the variable type is integer with format "decimal ascii value " and the frame specified is VALUE=XX (where XX is selected) and the frame received if VALUE=14, the value of the integer variable will be 14.

  • if the variable type is String with the Litteral String format and the frame specified is "Status=?!0D" (where '?' is selected) and the frame received is "Status=Playing!0D", then the value of variable will be "Playing". If the frame received is "Status=Paused!0D" then the value of the variable will be "Paused".

- Avanced Monitoring Variable Setup:

Clicking on the "Advanced" button of the Monitoring Variable Setup Dialog allows setting Bit Mask parameters.

The Bit Mask parameters are useful when the monitoring value embeds information in particular bits. A Bit Mask can only be applied to integer or integer enum values.

Available options are:

  • No Bit Mask: no special bit mask processing is done on the monitoring value

  • Use Bit: the monitoring value is equal to the value of the specified bit.
    The value is '1' if the specified bit is set.
    The value is '0' if the specified bit is not set.
    For example, if the value is '36' ( '24' in hexadecimal format or '00100100' in binary format) and the specified bit is bit #2, the value of the monitoring variable will be '1' because bit #2 is set.
    Note that bit numbers are zero based. Bit #0 is the rightmost bit in binary form.

  • Use Bit Range: the monitoring value is equal to the value of the specified bit range shifted to the right by the specified 'Shifted By' value.
    For example, if the value is '36' ( '24' in hexadecimal format or '00100100' in binary format) and the specified bit range is from bit #2 to bit #5 shifted by 2, the value of the monitoring variable will be '9' ('00001001' in binary format).
The Bit Mask processing is done after the format conversion ('Hexa ascii value', 'High-Low bytes', etc.) is applied.


AUTOMATION



This page tells when the device will make the connection (for example the opening of the port for a serial device).

- On Manager start: the connection is done when Manager enters run or debug mode.
- On "Open" command: the connection is done only when the command "Open" is called.
- On sending: the connection is done just before sending a frame.

- On Manager stop: the disconnection is done when Manager enters stop mode.
- On "Close" command: the disconnection is done only when the command "Close" is called.
- On receiving after xx ms: the disconnection is done xx milliseconds after receiving a valid frame.


DRIVERS



The drivers can be saved into ascii files.
These files have the INI format and can be edited by double-clicking on them.
They are located in the Low Level Communicator Drivers directory of the MxMs folder of Manager.

These drivers are used to store the parameters in another place than the Manager project, so that they can be easily re-used and exchanged.

After the setup of the device is done, the driver file is no more used since the parameters are saved also in the Manager project.

If a driver has been previously loaded from a file and the parameters of this driver have been modified, the modifications are automatically saved in the original file. However the changes are not automatically applied to other devices of the project which use the same driver. In order to apply the modifications, the driver file must be manually loaded in each of these devices.

Note that Low Level Communicator Drivers can also be downloaded from the Medialon WEB site http://www.medialon.com/download/ktor_drivers/.


TEST



In this window, you can test the frames.
In can be useful for verifying a checksum, for example
The format of the frame that would be sent takes in account all the parameters of the other pages.

> Top


Commands (List Of):

Some commands are available only for specified types. The types are written into brackets besides the command.
User commands defined in the device setup are added to this command set.

Open (all types)

Definition : Open the communication.
Parameters: no parameters
Usage: This command can be called if the opening of the communication is not set to automatic in the setup of the device.

Close (all types)

Definition : Close the communication.
Parameters: no parameters
Usage: This command can be called if the closing of the communication is not set to automatic in the setup of the device.

Send frame (Serial, TCP/Client, MIDI,TCP/IP Server, UDP/IP Client-Server )

Definition : Send the specified frame.
Parameters:
Output frame [Type: String] The frame to send.
Usage
: In TCP/IP server mode the frame is sent to all of the connected clients. In UDP/IP Client-Server mode, the frame is send to the default destination address and port.

Send frame to (TCP/IP Server) ( TCP/Server is not available in lite version )

Definition : Send the specified frame to a client.
Parameters:
Output frame [Type: String] The frame to send.

Address [Type: String] Address of the client connected to send to. Several client addresses (separated by a comma, space, dot, line feed or carriage return) can be specified. The "ClientsList" device system variable can be used as the address.

Send frame to (UDP/IP Client-Server)

Definition : Send the specified frame to a client.
Parameters:
Output frame [Type: String] The frame to send.

Address [Type: String] Address of the computer to send to.

Port [Type: Integer] Port of the computer to send to.

Get last frame ((Serial, TCP/Client, MIDI)

Definition : Read a frame from the next incoming frame buffer list.
Parameters:
Input frame [Type: String] The string that will be filled with the incoming frame in return.
Usage: This command must be called when the variable FramesCount (see below) becomes not null. This variable indicates the count of incoming frames waiting to be read.
Each time a frame is read with this command, the variable FramesCount is decreased by one and the frame read is punched out of the buffer list.

Get frame (TCP/IP Server, UDP/IP Server) ( TCP/Server is not available in lite version )

Definition : Read a frame from the next incoming frame buffer list.
Parameters:
Input frame [Type: String] The string that will be filled with the incoming frame in return.
Client address [Type: String] The address of the computer that has sent the frame.
Usage: This command must be called when the variable FramesCount (see below) becomes not null. This variable indicates the count of incoming frames waiting to be read.
Each time a frame is read with this command, the variable FramesCount is decreased by one and the frame read is punched out of the buffer list.

The addresses can be retreived in the ClientsList variable.

Get byte (all types)

Definition : Read a byte from the last incoming frame.
Parameters:
Return ascii value [Type: String] The string that will be filled with the byte value (see usage)
Byte index [Type: Integer] The index of the byte in the frame
Usage: This command can be called when the variable FramesCount is not null. When a byte is read with this command, the variable FramesCount is NOT decreased by one and the frame remains in the list (see command above: "Get Frame" for punching out the frame).
The Return ascii value can contain an hexadecimal representation of the byte, if it is not litteral, like it has been set in the setup of the device for the sending of hexadecimal character ( for example !0D )

Change count of bytes (all types)

Definition : Change the count of byte that the device is waiting for (incoming count of bytes).
Parameters:
Count of bytes [Type: Integer] New count of bytes.
Usage: In many protocols, the count of by of the responding frames depends of the type of command frame sent. This is the purpose of this command.

Set DTR (serial)

Definition : Change the DTR signal.
Parameters:
DTR value [Type: Integer] New value (0 or 1).


Set RTS (serial)

Definition : Change the RTS signal.
Parameters:
RTS value [Type: Integer] New value (0 or 1).

Get client name (TCP/IP Server) ( TCP/Server is not available in lite version )

Definition : Return the name of the specified client.
Parameters:
Address [Type: String] Address of the client.
Return name [Type: String] The string that will contain the address in return.

Change IP parameters (TCP/IP Client, TCP/IP Server, UDP/IP Server) ( TCP/Server is not available in lite version )

Definition : Set new IP parameters for this device.
Parameters:
Address [Type: String] New address.
Port [Type: Integer]: New port.

> Top


Variables (List Of):

Only the default variables are listed here.
New variables can be created in the Monitoring page of the setup dialog.

Status :

Type : Enum.
Description: Status of the connection.
Available values:
Closed: the connection is closed.
Opened: the connection is opened.
Error: no connection due to an error.
Adapter Address Error:
The specified adapter address for reception is not present in this machine.

LastCommandStatus :

Type : Enum.
Description: Status of the current command.
Available values:
Success: the command has been succesfully executed.
Pending: the command is currently executed.
Error: the command could not be executed.

Frames count:

Type : Integer.
Description: Count of incoming frames.
Usage:: This variable indicates the count of incoming frames waiting to be read.
Each time a frame is read with the command "Read frame", the variable FramesCount is decreased by one and the frame read is punched out of the buffer list.


Input bytes count:

Type : Integer.
Description: Count of incoming bytes of the current frame.
Usage:: This variable indicates the count of incoming bytes that are filling the current frame. If there are several frames in the queue, it does not represent the total of bytes of all the frames, but only the count of bytes of the last frame received. It can be useful when the parameters "count of bytes" and "timeout" are set to zero in the setup of the device with a protocole with variable length frame.

Last received frame:

Type : String.
Description: The last frame received on input.
Usage:: You can use this variable for reading the input frames, but be aware that if the frames arrive too fast, the variable can be overwritten by the next frame, while you read it (if it is the case, use "Keep all the input frames in memory" and the "Get Frame" command).

Clients count:

Type : Integer.
Description: Count of connected clients (in TCP/IP Server mode).

Clients list:

Type : String.
Description: List of connected clients.

DSR status:

Type : Integer.
Description: Current DSR status (serial device).

CTS status:

Type : Integer.
Description: Current CTS status (serial device).

> Top


Support (Difference with previous versions):

V 1.0.1:

  • Bug Fixed: crash if a negative value is used as an index of an enum parameters in a user command.

V 1.0.2:

  • Added: Support for Showmaster.

V 1.0.3:

  • Corrected: Button font color corrected in the setup dialog.
  • Modified: "Automation/On project load" and "Automation/On project unload" options have been removed from the setup dialog.
  • Corrected: The value was not returned by "Get Last Frame" if the return variable was not a string type.
  • Corrected: The value was not returned by "Get Byte" if the return variable was not a string type.
  • Corrected: When "Get Byte" was called, the expected count of byte was changed in the setup.
  • Fixed: False error detected when loading a project with deleted (strikethrough) cues. This bug fix requires Manager 5.0.2 or higher.
  • Fixed: Crash when sending a user command with a very large command frame containing user parameters.
  • Fixed: The break character is not analyzed if the frame does not contain a check-sum.

V 1.0.4:

  • Fixed: random crash when "Get Last Frame" command is executed while receiving data.
  • Fixed: Incorrect parsing of variable data from incoming frame with fixed and variable length bytes.
  • Fixed: In the setup, the user can enter the same character for all the special character.
  • Modified: better TCP Client Connection/Disconnection management if the specified server machine is not present.
  • Fixed: user command enum variables are not created if the command frame length is greater than 4Ko.
  • Fixed: user command frames are truncated when read from the driver file if the command frame length is greater than 2Ko.

V 1.0.5:

  • Fixed: impossible to specify the address and the port to which the monitoring udp frames are periodically sent (fixed by adding default destination parameters).
  • Improvement: "Send Frame" can be used in UDP Client-Server mode (with the default destination parameters specified in the setup).
  • Improvement: When the setup of a device using a driver is changed, the user is offered three possibilities of saving ( device only, device and driver, new deriver ).
  • Fixed: Incorrect parsing of variable data from incoming frame with fixed and variable length fields when the variable monitoring frame segment also contains regular (non wildcard) characters.

V 1.0.6:

  • Fixed: In the setup, adding a parameter at the start of a command deletes the whole frame.
  • Fixed: the command text is not computed if it starts by the bracket of a parameter description.

V 1.0.7:

  • Fixed: Incorrect parsing of variable data from incoming frame with fixed and variable length fields when there are one or more fixed length fields after the last variable length field.
  • Added: Support for Showmaster Pro.

V 1.0.8:

  • Added: Monitoring Variable bit mask processing.

V 1.0.9:

  • Fixed: Inner values of IP Address containing leading zero are converted from octal values instead of decimal.

V 1.0.10:

  • Fixed: Default UDP parameters are not used in User Commands and 'Send Frame To' command (UDP mode).

V 1.2.0:

  • Fixed: Cannot create more than 255 LowLevelCommunicator devices.

V 1.2.1:

  • Fixed: a parameter of a driver command is not processed if it is larger than 2048 bytes.

> Top