Q: Will it be possible to program the older DL-PLCs with DirectSOFT-MX?
A: No, only the MX-275 and MX-275e are currently programmable with DirectSOFT-MX.
Originally we intended to allow the programming of the older DL-PLCs, but as the design developed we realized by moving to strong data types and structures we were fundamentally changing the way we did some critical things which moved us further and further away from maintaining compatibility with DL-PLCs. So the decision was made to build the best controller and software we could instead of trying to maintain compatibility with DL-PLCs.
Q: Will there be a DirectSOFT6 for the older DL-PLCs?
A: Yes. After MX is rolled out, there are plans to do another major release of DirectSOFT for the older DL-PLCs.
Q: Why are there no ISG (Initial Stage) instructions?
A: In the DL-PLCs there is no program modularity and users are therefore forced to modularize their programs with stages and therefore multiple ISGs were needed. By contrast, MX-PLCs are designed to be modular (Tasks & Programs) with Programs supporting stages. Since each Program can have its own block of 128 stages running independently and the very first stage is the initial one, then the ISG instruction is not needed. This simplifies stages and encourages a better programming practice of having a single well-defined entry point for a sequence.
If multiple parallel sequences are needed in a
single program, use the DIVERGE instruction in the first stage or simply set the
other stages from the first stage.
In an MX-PLC, Programs should be thought of as individual sequencing operations and each sequencing operation should have one starting point.
Q: Does the MX-CPU have more memory than the DL260?
|Data||34 Kbytes||256 Kbytes|
|Program||15,872 instruction words||65,536 instruction words|
Q: Are the more complex high-level instructions (e.g. network R/W and Math) more efficient that IBoxes in the DL260?
A: Except for MATH, yes. IBoxes are just macros whereas all the complex instructions in MX are native and all of the interlocking to the instruction and device driver are internal. But as for MATH it is still much faster in the MX (e.g. integer MATH in MX is nearly as fast as the simple contact/coil instructions!).
Q: What is the typical scantime of an MX-PLC?
A: Like all things PLC, this is a wide open question. The minimum scan time is about 150 µs. Certain modules that tax the DL205 backplane a bit (e.g. CTRIO/CTRIO2) will raise that. With a single CTRIO2 in the base the minimum scan is about 258 µs. Boolean instructions, math and boolean stack operations, and most integer math operations are all very fast, generally running at about 50 ns per instruction, or 50 µs per K of logic.
More complex instructions, of course, will increase the scan accordingly. Given typical PLC programming the typical scantime will probably be submillisecond to a few milliseconds. So for most users, speed won't be an issue, especially if Stages and modularity mechanisms are utilized as intended.
Q: Will interrupts be supported?
A: Not at this point. We are considering come changes to that in the future, but it is not critical for the MX-PLC given its performance (speed).
Q: Is the serial communication half or full duplex?
A: Full duplex. It is possible to fill the MX base with H2-SERIO-4 modules and run MX Server, Modbus RTU Server, Modbus RTU Client, K-Sequence Server, or even custom protocols on every port simultaneously.
Q: How many Modbus TCP clients (masters) can talk to the MX-275e internal Ethernet port?
A: The MX-275e can maintain 16 connections as a Modbus TCP Server (slave). If the 17th master attempts a TCP connection, the MX-275e would simply reject the connection request.
Q: Will DirectSOFT-MX be free?
A: We have not decided yet. There are many pros and cons we are considering.
Q: Will there be any type of utility (like DNLoader) that the end customer can use to update their PLC without needing a copy of DirectSOFT-MX and without knowing the PLC password?
A: There are plans on having a very elaborate tool for MX that does this. This tool will button up firmware, program, and data into a single encrypted file and basically take an MX-PLC from an unknown state to ready to run.
Q: What kind of program security does MX have?
A: Each code block in an MX-PLCs can be individually configured as Full Access, Read Only, or Locked. When Locked, the block is not even viewable without a password.
Q: Is there a utility that will translate DL230, DL240, DL250(-1) and DL260 projects into MX projects?
A: Currently, no. Try exporting your DL boolean logic STR/AND/OR/OUT coil and with some minor edits to that file you might could get that to import to MX. However, there is no accumulator exposed via user instructions (i.e. no LD/OUT word, no LD LD LD OP type sequences), hence converting a higher level 240 to an MX program would be like converting assembly into C++, with lots of caveats. But the Export/Import could possibly convert 60-80% of the code with contact/coil, rung comments, and element documentation, but it's the last 20-40% that will need a complete rewrite in DirectSOFT-MX. And actually, it will probably be much easier to write the MX version due to the greatly enhanced high level functions.
Q: What communication protocols are supported by MX?
A: The following:
Write your own:
Q: Will current OPC servers for the DL-PLCs also work for the MX-CPU?
A: Yes, using either Modbus or K-sequence drivers. An MX driver for KepDirect is to be announced.
Q: What are the highest values for timers and counters?
A: Timers are all millisecond resolution using 32-bit signed numbers (-2,147,483,648 to +2,147,438,647), thus millisecond resolution for more than 24 days. Counters are also 32-bit signed numbers, hence you can count up to 2,147,438,647 or down to -2,147,438,648.
Q: Are the familiar DL-PLC memory types supported in MX-PLCs?
A: Most DL memory types also exist in an MX-PLC. X, Y, and C are Discrete Input, Discrete Output, and Internal Bits. However, MX element blocks are numbered in decimal, not octal. So, yes, there is an X8 (and an X9).
V memory in MX is a 16-bit unsigned integer, with a range of 0-65,535. Instead of storing 32-bit IEEE real numbers in V memory, or 32-bit integer in V memory, we created two additional memory blocks, R and D, respectively. Each element in the R block is a 32-bit real number. Each element in the D block is a 32-bit signed 2's complement integer number. Both of these blocks also have decimal IDs.
Use V memory when you need integer values 0-65535.
Use D memory when you need a signed integer.
Use R memory when you need real.
The good news is that the MATH instruction can properly handle mixing and matching any of these data types in MX. For instance, this is a valid MATH expression:
(ROUND(SQRT(R0)) + V8) * D3.
Timer/Counter bits and accumulator values are now part of Timer and Counter structures. T0 represents the entire Timer structure for timer T0. Within these structures are various "dot fields," e.g. .Done .Acc .Reset. To know when Timer #0 is done, enter T0.Done. To look at Counter #9's accumulator, enter CT9.Acc. This means that V0 is User V memory, not T0's accumulator like in the DL-PLCs. Also, all of the .Acc accumulators are 32-bit signed integers with a range of -2,147,438,648 to +2,147,438,647.
Q: Is there an instruction list for MX?
A: What follows is a complete instruction list for MX-275/275e CPUs:
Q: What do the PUBLISH and SUBSCRIB instructions do?
A: These instructions could possibly be needed when an external system is providing data or the MX-PLC is providing data to an external system and the data types do not exactly match. These instructions let you move/convert/align the data to MX memory locations. Both of these are table instructions, where for each row in the table instruction, you enter a source, destination and number of elements and the options for converting it.
Those options are:
The way it was envisioned was to stick one or more SUBSCRIB instructions in the Top of Scan task, and one or more PUBLISH instructions at the Bottom of Scan task, whose sole purpose is to move/convert data to/from 'public' memory and from/to 'internal' memory. Clean and well-bounded.
Q: Is there an OROUT instruction (or equivalent) so that an output can be controlled from more than one ladder rung?
A: There is no OROUT instruction or an equivalent. However the functionality of an OROUT can be implemented by using the system block $TopOfScan and an RST of the output there. Then elsewhere in the program use SET of that same output.
Q: The XRef (cross reference) only shows addresses. Can it show rung numbers instead?
A: The address that is shown is a link to the instruction that it is used in. Rung numbers map to multiple instructions. Just click on the link and it will take you to the rung and the block cursor will be overtop of the exact instruction. Once there, you can see the rung number in the margin. However, in a future version of MX we are considering keeping the link to be addressed based but the display you actually see is the rung number.
Q: How can I clear a string (SS or SL)?
A: Use the STRTRUNC instruction and set the length to 0 (which is the default).
Q: What is the functional equivalent to a DirectLOGIC LD (Load) instruction?
A: Use the INIT or MOVE instruction.