SLC Strings - PLCTAG_ERR_TOO_SMALL #58
Comments
|
Hi @IanRobo75 - thanks for trying this wrapper! The wrapper should be able to support anything that the native runtimes support, so it could be possible libplctag native doesn't support this - I'm not really sure. It is possible that the wrapper has some issues, you can make use of the libplctag.NativeImport package that provides raw access to the libplctag native functionality without any abstractions over the top - could be useful to try this. Also, are you using the latest prerelease? These packages are still in alpha. MicroLogic and SLC are different CPU types, could you try with both and see what the result is? |
|
I see that the wrapper does not expose the MicroLogix CPU Type. I’ll look at using the NativeImport and investigate.
Cheers,
Ian
Ian Robinson Machine Safety & Automation Engineer
[swarmIQ_colour 20%]
From: timyhac <notifications@github.com>
Sent: Monday, July 20, 2020 4:44 PM
To: libplctag/libplctag.NET <libplctag.NET@noreply.github.com>
Cc: IanRobo75 <ian@acompleteloss.com>; Mention <mention@noreply.github.com>
Subject: Re: [libplctag/libplctag.NET] SLC Strings - PLCTAG_ERR_TOO_SMALL (#58)
Hi @IanRobo75<https://github.com/IanRobo75> - thanks for trying this wrapper!
The wrapper should be able to support anything that the native runtimes support, so it could be possible libplctag native doesn't support this - I'm not really sure.
It is possible that the wrapper has some issues, you can make use of the libplctag.NativeImport package that provides raw access to the libplctag native functionality without any abstractions over the top - could be useful to try this.
Also, are you using the latest prerelease? These packages are still in alpha.
MicroLogic and SLC are different CPU types, could you try with both and see what the result is?
https://github.com/libplctag/libplctag/wiki/Tag-String-Attributes
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#58 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AIY6RY3MLTPIP5TTGOJZJPDR4PDQDANCNFSM4PB255VQ>.
|
|
Sorry for the email response. One thing to try is a different size. I
think strings on PCCC-based PLCs are either 82 or 84 bytes, not 88.
Best,
Kyle
…On Mon, Jul 20, 2020, 12:26 PM IanRobo75 ***@***.***> wrote:
I see that the wrapper does not expose the MicroLogix CPU Type. I’ll look
at using the NativeImport and investigate.
Cheers,
Ian
Ian Robinson Machine Safety & Automation Engineer
[swarmIQ_colour 20%]
From: timyhac ***@***.***>
Sent: Monday, July 20, 2020 4:44 PM
To: libplctag/libplctag.NET ***@***.***>
Cc: IanRobo75 ***@***.***>; Mention ***@***.***>
Subject: Re: [libplctag/libplctag.NET] SLC Strings - PLCTAG_ERR_TOO_SMALL
(#58)
Hi @IanRobo75<https://github.com/IanRobo75> - thanks for trying this
wrapper!
The wrapper should be able to support anything that the native runtimes
support, so it could be possible libplctag native doesn't support this -
I'm not really sure.
It is possible that the wrapper has some issues, you can make use of the
libplctag.NativeImport package that provides raw access to the libplctag
native functionality without any abstractions over the top - could be
useful to try this.
Also, are you using the latest prerelease? These packages are still in
alpha.
MicroLogic and SLC are different CPU types, could you try with both and
see what the result is?
https://github.com/libplctag/libplctag/wiki/Tag-String-Attributes
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<
#58 (comment)>,
or unsubscribe<
https://github.com/notifications/unsubscribe-auth/AIY6RY3MLTPIP5TTGOJZJPDR4PDQDANCNFSM4PB255VQ>.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#58 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAN4LC2OI7XVMRQR5UN2YY3R4SK5RANCNFSM4PB255VQ>
.
|
OK will do. I see the latest alpha has the MicroLogix PLC type as well, which was missing from the release version. So I'll try that as well. |
|
This is interesting - it means we will have to have different marshallers for different CPU types. |
|
OK, so I believe the base library does not easily support strings for PLC5/ SLC/ MicroLogix comms. I can read a string if I put the correct length in for the string (i.e. if the string in the PLC is "ABC" and I set the tag length as 3 then it works). Getting the length attribute dynamically is too hard for me and not worth the effort. My next task is to communicate with a CompactLogix, I expect strings will be fine there. |
|
So reads of DINT are not working? That's not good! Can you please create a dump when trying to read a L file (debug level 4)? I can try to see if there is something obvious about the error code. I only have a PLC/5 to test on, so all that is guess work on my part. Strings are quite painful. However, I can see what I can do to make the reads easier in the core library. With Control/Compact Logix systems, I just allocate the tag buffer as I am reading in the data. For PCCC-based systems (MicroLogix, SLC, PLC/5), I do not. I will see if there is anything I can do to make that work as well. Then you could read a string in. The problem is when you want to read a string in and then write out a longer string. Then there is no buffer space. I may need to special case strings. They are not an atomic type like INT and they are not an array and they are not a UDT. And they seem to be quite different on Micro800 PLCs too. |
Thank AB. There are three string formats that I am aware of:
AB is NOT a single family. It is at least three. Multiple times I have come close to splitting the code into three completely separate sections for the different PLC types. And there are significant differences between PLC/5, SLC and MicroLogix. The latter two are quite similar but seem to support different maximum packet sizes. But commands for a PLC/5 rarely work for SLC/MicroLogix and vice versa. |
|
Thanks Kyle! @IanRobo75 - RSLogix provides the tag size when you browse the controller data types, at least for CompactLogix, I'm not sure how this works for other CPU types (or other versions of RSLogix for that matter). @kyle-github - One thing I was thinking about doing was providing some guidance on how to reverse-engineer the binary format of a tag (assuming you already know the tag size). I've ended up using a combination of Rockwell manuals and hex-format viewing to get this working for an array of UDTs with embedded Structures - seems to work OK but it's not straightforward. |
|
Ye, I’m pretty sure it will work for Logix. Standard CLX (Logix) strings are 88 bytes and you can create your own string types of different lengths as well (not a big requirement for this).
SLC/ML addresses are variable length (well at least that how they are presented). MicroLogix example (looks the same for SLC)…
[cid:image001.png@01D65F67.57D7F7D0]
For the above example I can set up a tag ST102:0 as length 25 and it reads OK. Any more or less length and it doesn’t read (TOO SMALL or TOO BIG error codes).
As I said before it’s not a big issue for me as we’ll only probably read Strings from CLX PLCs. Also, we just change L to N in addresses, I: to N1, and o: no N0, before reading/writing, and set the length appropriately.
I haven’t time to test too far since completing my project is #1 priority.
Cheers,
Ian
Ian Robinson Machine Safety & Automation Engineer
[swarmIQ_colour 20%]
From: timyhac <notifications@github.com>
Sent: Tuesday, July 21, 2020 1:49 PM
To: libplctag/libplctag.NET <libplctag.NET@noreply.github.com>
Cc: IanRobo75 <ian@acompleteloss.com>; Mention <mention@noreply.github.com>
Subject: Re: [libplctag/libplctag.NET] SLC Strings - PLCTAG_ERR_TOO_SMALL (#58)
Thanks Kyle!
@IanRobo75<https://github.com/IanRobo75> - RSLogix provides the tag size when you browse the controller data types, at least for CompactLogix, I'm not sure how this works for other CPU types (or other versions of RSLogix for that matter).
[image]<https://user-images.githubusercontent.com/19144307/88003299-de3ede00-cb47-11ea-9de8-99b954eb9673.png>
@kyle-github<https://github.com/kyle-github> - One thing I was thinking about doing was providing some guidance on how to reverse-engineer the binary format of a tag (assuming you already know the tag size). I've ended up using a combination of Rockwell manuals and hex-format viewing to get this working for an array of UDTs with embedded Structures - seems to work OK but it's not straightforward.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#58 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AIY6RY566XLDPZSOPENRZH3R4TXXHANCNFSM4PB255VQ>.
|
|
By the way. Here’s the actual format of a string as presented in Studio5000….
[cid:image001.png@01D65F6B.0287EC50]
4 bytes for LENgth + 82 bytes for character codes +2 for something else unknown to me.
Cheers,
Ian
Ian Robinson Machine Safety & Automation Engineer
[swarmIQ_colour 20%]
From: timyhac <notifications@github.com>
Sent: Tuesday, July 21, 2020 1:49 PM
To: libplctag/libplctag.NET <libplctag.NET@noreply.github.com>
Cc: IanRobo75 <ian@acompleteloss.com>; Mention <mention@noreply.github.com>
Subject: Re: [libplctag/libplctag.NET] SLC Strings - PLCTAG_ERR_TOO_SMALL (#58)
Thanks Kyle!
@IanRobo75<https://github.com/IanRobo75> - RSLogix provides the tag size when you browse the controller data types, at least for CompactLogix, I'm not sure how this works for other CPU types (or other versions of RSLogix for that matter).
[image]<https://user-images.githubusercontent.com/19144307/88003299-de3ede00-cb47-11ea-9de8-99b954eb9673.png>
@kyle-github<https://github.com/kyle-github> - One thing I was thinking about doing was providing some guidance on how to reverse-engineer the binary format of a tag (assuming you already know the tag size). I've ended up using a combination of Rockwell manuals and hex-format viewing to get this working for an array of UDTs with embedded Structures - seems to work OK but it's not straightforward.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#58 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AIY6RY566XLDPZSOPENRZH3R4TXXHANCNFSM4PB255VQ>.
|
|
@IanRobo75 , for some reason that is not coming through for me. Strings are clearly a problem. They are a special UDT that is common enough that there should probably be a way to deal with them that is not so painful. Right now, the only way to deal with them is to allocate the full 82 characters plus space for the length word. But on ControlLogix (and Micro800), we do not actually know that we are dealing with STRING types until we read the tag. At least with PCCC PLCs, you have the data file type, so the tag size could be set initially. I'll have to think about this a bit. |
|
The case where String tags are static in size would be relatively easy to handle in the wrapper, the Encoder/Decoder/Marshaller just needs to know which Cpu type its targeting, and change its logic accordingly. My understanding (based on some tests of string arrays), is that even though the LEN property tells us how many characters are in the string, the size of the entire tag is always 88 bytes, so if LEN was 12, then there would be 12 ASCII characters, and then 70 null characters. If the actual size of the tag changes depending on the data in it, then that would be tricky... It would have to be two round trips.... Hmmm... |
|
Probably true about the actual length of a String in a Micrologix/SLC actually being 82 characters (bytes) + 2 bytes for the .LEN in the PLC (not 88, that is Logix only). However I found you can’t always set the libplctag.NET read tag length as 82, I just errors. I had to set the length of the libplctag.NE tag to the actual number of characters in the string (as seen in the LEN property in the PLC) for it not to error. So maybe the wrapper would need 2 trips, one to read LEN (e.g. 12) and then another to read that number of characters and put them in the 82 long string with null padding after that (e.g. from characters 13 to 82). I hope that makes sense.
From: timyhac <notifications@github.com>
Sent: Tuesday, 21 July 2020 8:09 PM
To: libplctag/libplctag.NET <libplctag.NET@noreply.github.com>
Cc: IanRobo75 <ian@acompleteloss.com>; Mention <mention@noreply.github.com>
Subject: Re: [libplctag/libplctag.NET] SLC Strings - PLCTAG_ERR_TOO_SMALL (#58)
The case where String tags are static in size would be relatively easy to handle in the wrapper, the Encoder/Decoder/Marshaller just needs to know which Cpu type its targeting, and change its logic accordingly.
My understanding (based on some tests of string arrays), is that even though the LEN property tells us how many characters are in the string, the size of the entire tag is always 88 bytes, so if LEN was 12, then there would be 12 ASCII characters, and then 70 null characters.
If the actual size of the tag changes depending on the data in it, then that would be tricky... It would have to be two round trips.... Hmmm...
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#58 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AIY6RY3GPVY3CHHEZCOKYG3R4VELBANCNFSM4PB255VQ>.
|
|
I seem to remember cases where some PCCC PLCs return just the string data and the length without any padding. Does anyone have a MicroLogix or SLC to test that theory? If that is true, then the core library needs to have some additions in order to recognize string types and behave correctly. For *Logix PLCs, you get the whole string buffer, so there is always space. But in cases where you do not get the whole buffer the library will need to change behavior because PCCC PLCs do not return a status indicating that there is more data left. You just get what you get in the packet. |
|
I definitely want to avoid multiple round trips, so the important check here is to see if anything returns variable length results. |
Thank AB. There are three string formats that I am aware of:
AB is NOT a single family. It is at least three. Multiple times I have come close to splitting the code into three completely separate sections for the different PLC types. And there are significant differences between PLC/5, SLC and MicroLogix. The latter two are quite similar but seem to support different maximum packet sizes. But commands for a PLC/5 rarely work for SLC/MicroLogix and vice versa. |
|
So, I created a project using libplctag.NativeImport and I can read a string from a MicroLogix on problem, element Size 84 (2 + 82), read a UINT for the string size, then read that number of characters. The character are byte-swapped so I deal with that as well.
Here’s example results…
[cid:image001.png@01D6600F.115F1BF0] [cid:image003.png@01D66010.32F81270]
Can’t do that with the normal wrapper.
This nativeimport version is much more usable for us since we in our program define the tag type and size anyway so can just deal with string as I have done in this example.
And here’s the Windows forms code for that:
using System;
using System.Diagnostics;
using System.Windows.Forms;
using libplctag.NativeImport;
namespace libplctagTest
{
public partial class frmMain : Form
{
public frmMain()
{
InitializeComponent();
}
private void btnTest_Click(object sender, EventArgs e)
{
//constants
const int STATUS_OK = 0;
const int VER_MAJOR = 2;
const int VER_MINOR = 1;
const int VER_PATCH = 0;
int elementCount = 1;
int elementSize =84;
string tagname = "ST102:1";
string path = "protocol=ab_eip" +
"&gateway=192.168.5.151" +
"&cpu=MicroLogix" +
"&elem_size=" + elementSize.ToString() +
"&elem_count =" + elementCount.ToString() +
"&name=" + tagname +
"&debug=1";
//clear result textbox on form
tbResult.Clear();
// check the library version.
if (plctag.check_lib_version(VER_MAJOR, VER_MINOR, VER_PATCH) != STATUS_OK)
{
Debug.Print("Required compatible library version 2.1.0 not available!\n");
return;
}
//create tag
Int32 tag = plctag.create(path, 5000);
//check could be created
if (tag < 0)
{
Debug.Print("ERROR " + plctag.decode_error(tag) + " : Could not create tag!\n");
return;
}
//check for error
if (plctag.status(tag) != STATUS_OK)
{
Debug.Print("Error setting up tag internal state. Error " + plctag.decode_error(tag) + "\n");
plctag.destroy(tag);
return;
}
int rc = plctag.read(tag, 5000);
if (rc != STATUS_OK)
{
Debug.Print("ErRROR: Unable to read the data! Got error code " + rc.ToString() + " : " + plctag.decode_error(rc) + "\n");
plctag.destroy(tag);
return;
}
/* print out the data */
for (int i = 0; i < elementCount; i++)
{
//get the string size (from byte 0)
int iStringSize = plctag.get_int16(tag, (i * elementSize));
tbResult.Text += "String LEN = " + iStringSize.ToString() + Environment.NewLine;
tbResult.Text += "--------------------------------------------" + Environment.NewLine;
string sb = "";
string charBuffer = "";
//string result = tagname + ", element " + i.ToString() + "=" + plctag.get_int16(tag, (i * elementSize)) + "\n";
for (int j = 2; j < iStringSize +2; j++)
{
int iresult = plctag.get_uint8(tag, (i * elementSize) + j);
string result = tagname +
", element " + i.ToString() +
", byte " + j.ToString() +
"=" + iresult.ToString() +
"\t= " + ((char)iresult).ToString();
Debug.Print(result+ Environment.NewLine);
tbResult.Text += result + Environment.NewLine;
if (iresult == 0) { tbResult.Text += Environment.NewLine; }
if (j % 2 == 0)
{
//even so buffer character
charBuffer = ((char)iresult).ToString();
}
else
{
//odd so add new character, then buffered, and clear buffer
sb += ((char)iresult).ToString() + charBuffer;
charBuffer = "";
}
}
//add any remaining buffer char
sb += charBuffer;
tbResult.Text += "--------------------------------------------" + Environment.NewLine;
tbResult.Text += tagname + " Full String = '" + sb + "'" + Environment.NewLine;
}
}
}
}
Cheers,
Ian
Ian Robinson Machine Safety & Automation Engineer
[swarmIQ_colour 20%]
From: Kyle Hayes <notifications@github.com>
Sent: Wednesday, July 22, 2020 2:39 AM
To: libplctag/libplctag.NET <libplctag.NET@noreply.github.com>
Cc: IanRobo75 <ian@acompleteloss.com>; Mention <mention@noreply.github.com>
Subject: Re: [libplctag/libplctag.NET] SLC Strings - PLCTAG_ERR_TOO_SMALL (#58)
I definitely want to avoid multiple round trips, so the important check here is to see if anything returns variable length results.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#58 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AIY6RY4RHTAE6A7AJQVGIT3R4WSB5ANCNFSM4PB255VQ>.
|
|
ah, libplctag.NativeImport is good for strings but doesn’t let me read L9:5 from a ML (MicroLogix).
The normal wrapper let me read is as N9:4 with element size of 4 but I can’t get the native wrapper to read it at all (PLCTAG_ERR_BAD_PARAM).
Cheers,
Ian
Ian Robinson Machine Safety & Automation Engineer
[swarmIQ_colour 20%]
From: Ian Robinson
Sent: Wednesday, July 22, 2020 10:13 AM
To: libplctag/libplctag.NET <reply@reply.github.com>
Subject: RE: [libplctag/libplctag.NET] SLC Strings - PLCTAG_ERR_TOO_SMALL (#58)
So, I created a project using libplctag.NativeImport and I can read a string from a MicroLogix on problem, element Size 84 (2 + 82), read a UINT for the string size, then read that number of characters. The character are byte-swapped so I deal with that as well.
Here’s example results…
[cid:image004.png@01D66014.1B63DC30][cid:image005.png@01D66014.1B63DC30]
Can’t do that with the normal wrapper.
This nativeimport version is much more usable for us since we in our program define the tag type and size anyway so can just deal with string as I have done in this example.
And here’s the Windows forms code for that:
using System;
using System.Diagnostics;
using System.Windows.Forms;
using libplctag.NativeImport;
namespace libplctagTest
{
public partial class frmMain : Form
{
public frmMain()
{
InitializeComponent();
}
private void btnTest_Click(object sender, EventArgs e)
{
//constants
const int STATUS_OK = 0;
const int VER_MAJOR = 2;
const int VER_MINOR = 1;
const int VER_PATCH = 0;
int elementCount = 1;
int elementSize =84;
string tagname = "ST102:1";
string path = "protocol=ab_eip" +
"&gateway=192.168.5.151" +
"&cpu=MicroLogix" +
"&elem_size=" + elementSize.ToString() +
"&elem_count =" + elementCount.ToString() +
"&name=" + tagname +
"&debug=1";
//clear result textbox on form
tbResult.Clear();
// check the library version.
if (plctag.check_lib_version(VER_MAJOR, VER_MINOR, VER_PATCH) != STATUS_OK)
{
Debug.Print("Required compatible library version 2.1.0 not available!\n");
return;
}
//create tag
Int32 tag = plctag.create(path, 5000);
//check could be created
if (tag < 0)
{
Debug.Print("ERROR " + plctag.decode_error(tag) + " : Could not create tag!\n");
return;
}
//check for error
if (plctag.status(tag) != STATUS_OK)
{
Debug.Print("Error setting up tag internal state. Error " + plctag.decode_error(tag) + "\n");
plctag.destroy(tag);
return;
}
int rc = plctag.read(tag, 5000);
if (rc != STATUS_OK)
{
Debug.Print("ErRROR: Unable to read the data! Got error code " + rc.ToString() + " : " + plctag.decode_error(rc) + "\n");
plctag.destroy(tag);
return;
}
/* print out the data */
for (int i = 0; i < elementCount; i++)
{
//get the string size (from byte 0)
int iStringSize = plctag.get_int16(tag, (i * elementSize));
tbResult.Text += "String LEN = " + iStringSize.ToString() + Environment.NewLine;
tbResult.Text += "--------------------------------------------" + Environment.NewLine;
string sb = "";
string charBuffer = "";
//string result = tagname + ", element " + i.ToString() + "=" + plctag.get_int16(tag, (i * elementSize)) + "\n";
for (int j = 2; j < iStringSize +2; j++)
{
int iresult = plctag.get_uint8(tag, (i * elementSize) + j);
string result = tagname +
", element " + i.ToString() +
", byte " + j.ToString() +
"=" + iresult.ToString() +
"\t= " + ((char)iresult).ToString();
Debug.Print(result+ Environment.NewLine);
tbResult.Text += result + Environment.NewLine;
if (iresult == 0) { tbResult.Text += Environment.NewLine; }
if (j % 2 == 0)
{
//even so buffer character
charBuffer = ((char)iresult).ToString();
}
else
{
//odd so add new character, then buffered, and clear buffer
sb += ((char)iresult).ToString() + charBuffer;
charBuffer = "";
}
}
//add any remaining buffer char
sb += charBuffer;
tbResult.Text += "--------------------------------------------" + Environment.NewLine;
tbResult.Text += tagname + " Full String = '" + sb + "'" + Environment.NewLine;
}
}
}
}
Cheers,
Ian
Ian Robinson Machine Safety & Automation Engineer
[swarmIQ_colour 20%]
From: Kyle Hayes <notifications@github.com<mailto:notifications@github.com>>
Sent: Wednesday, July 22, 2020 2:39 AM
To: libplctag/libplctag.NET <libplctag.NET@noreply.github.com<mailto:libplctag.NET@noreply.github.com>>
Cc: IanRobo75 <ian@acompleteloss.com<mailto:ian@acompleteloss.com>>; Mention <mention@noreply.github.com<mailto:mention@noreply.github.com>>
Subject: Re: [libplctag/libplctag.NET] SLC Strings - PLCTAG_ERR_TOO_SMALL (#58)
I definitely want to avoid multiple round trips, so the important check here is to see if anything returns variable length results.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#58 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AIY6RY4RHTAE6A7AJQVGIT3R4WSB5ANCNFSM4PB255VQ>.
|
|
Thanks for checking this Ian. Very interesting that the characters are byte swapped! I have no experience with MicroLogix - are "N" tags 16 bits (element size = 2)? Update: 16bits not bytes |
|
@IanRobo75 - please not I've just released a new (still alpha) version of NativeImport. Main difference for you is the names of the methods have changed to 100% reflect the C API. |
|
@IanRobo75, thanks for the checks. I had a report a while back of byte swapped character pairs in strings but I never was able to replicate it. That says to me that I need to treat strings as a completely different data type in the core library. Note that strings are different across different PLCs. I had to update some PLC/5 code recently because the words within a REAL were byte swapped. |
|
Micrologix types just like SLC500 and PLC5, although I think there are no L files in PLC5…
B Bits, but 16-bit signed Integers really (in the PLC you can reference them as individual bits as well as integer/Bit, so B3/16 is also B3:1/0) (element size = 2)
N 16-bit signed Integer (element size = 2)
L 32-bit signed Integer (element size = 4)
F 32-bit Float (IEEE 754 binary 32) (element size = 4)
ST 82 char string (+ 2 preceding bytes for Length) (element size = 84)
also…
A 2 ASCII characters - forget about these
T Timer structure - forget about these
C Counter structure - forget about these
R Control structure - forget about these
M Message structure - forget about these
PD PID structure - forget about these
O & I Special case of N - forget about these.
Logix types are much more standard...
BOOL Boolean bit (can also have arrays of in groups of 32 e.g. testBOOL[64])
SINT 8-bit signed integer (can also have up to 3 dimensions of arrays, e.g. testSINT[5,10,15])
INT 16-bit signed integer (can also have up to 3 dimensions of arrays, e.g. testINT[5,10,15])
DINT 32-bit signed integer (can also have up to 3 dimensions of arrays, e.g. testDINT[5,10,15])
LINT 64-bit signed integer (can also have up to 3 dimensions of arrays, e.g. testLINT[5,10,15])
REAL 32-bit real (IEEE 754 binary 32)) (can also have up to 3 dimensions of arrays, e.g. testREAL[5,10,15])also…
TIMER
COUNTER
CONTROL
MESSAGE
other types & user defined types (structures).
Cheers,
Ian
Ian Robinson Machine Safety & Automation Engineer
[swarmIQ_colour 20%]
From: timyhac <notifications@github.com>
Sent: Wednesday, July 22, 2020 11:11 AM
To: libplctag/libplctag.NET <libplctag.NET@noreply.github.com>
Cc: IanRobo75 <ian@acompleteloss.com>; Mention <mention@noreply.github.com>
Subject: Re: [libplctag/libplctag.NET] SLC Strings - PLCTAG_ERR_TOO_SMALL (#58)
Thanks for checking this Ian. Very interesting that the characters are byte swapped!
I have no experience with MicroLogix - are "N" tags 16 bytes (element size = 2)?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#58 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AIY6RY3LQBSNQBPWTISQT2TR4YOBFANCNFSM4PB255VQ>.
|
Yep, makes sense, I've updated my ML test example accordingly. Still can't read L9:5 though (using libplctag), even as N9:5; get PLCTAG_ERR_BAD_PARAM. Here's the level 4 debug... 2389-06-22 12:11:25.236 thread(1) tag(0) INFO find_tag_create_func:95 Matched protocol=ab_eip |
|
Interesting - what is the full attribute string for this tag? I don't think I can help but it might clarify. |
|
Here are my results reading different MicroLogix data types with libplctag.NativeImport ... How to read the data successfully... Note all the working ones are 16-bit integers [element size 2] + the string [element size 84]. |
|
Well that points to the problem!
Looks like I am not handling the I am using PLC/5-specific commands to read my PLC/5 and with those (but not the commands I was using!) I see the byte swapped characters as well. But the count/LEN field is little-endian. Oh how I love AB. |
|
from here... https://www.sciencedirect.com/science/article/pii/S1742287617301998 looks like the L file is file type 0x91 in the PCCC protocol... Test Cases | Classified File-typeData Files/New/select Type:Binary | – | New file B9 | 0x85 |
|
@kyle-github - if you'd prefer to handle strings in the C library that is Ok, but it is relatively easy to develop marshalling logic based on Cpu type - although it would mean that all of the wrappers would need to implement this separately. |
|
would be better if the wrapper handled it of course. The wrapper could also change O to O0, I to I1, and S to S2 in the addresses (e.g. O:0 become O0:0).
Cheers,
Ian
Ian Robinson Machine Safety & Automation Engineer
[swarmIQ_colour 20%]
From: timyhac <notifications@github.com>
Sent: Wednesday, July 22, 2020 1:41 PM
To: libplctag/libplctag.NET <libplctag.NET@noreply.github.com>
Cc: IanRobo75 <ian@acompleteloss.com>; Mention <mention@noreply.github.com>
Subject: Re: [libplctag/libplctag.NET] SLC Strings - PLCTAG_ERR_TOO_SMALL (#58)
@kyle-github<https://github.com/kyle-github> - if you'd prefer to handle strings in the C library that is Ok, but it is relatively easy to develop marshalling logic based on Cpu type - although it would mean that all of the wrappers would need to implement this separately.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#58 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AIY6RY6735KLGRC7U5CRSY3R4Y7SLANCNFSM4PB255VQ>.
|
|
Version 2.1.10 is released. This should have support for PCCC long integers in the C core library. |
|
0.0.9-alpha of libplctag.NativeImport has been released that includes these binaries. @IanRobo75 - in some testing I've found that if you set the target platform to x86 then NativeImport will not be able to interop with the x64 binary despite running on an x64 machine. This could be related to your BadImageFormatException. |
|
Using 0.0.9-alpha of libplctag.NativeImport… L9:5 read fine from MicroLogix, so PCCC long integers OK.
Cheers,
Ian
Ian Robinson Machine Safety & Automation Engineer
[swarmIQ_colour 20%]
From: timyhac <notifications@github.com>
Sent: Sunday, July 26, 2020 12:09 PM
To: libplctag/libplctag.NET <libplctag.NET@noreply.github.com>
Cc: IanRobo75 <ian@acompleteloss.com>; Mention <mention@noreply.github.com>
Subject: Re: [libplctag/libplctag.NET] SLC Strings - PLCTAG_ERR_TOO_SMALL (#58)
0.0.9-alpha of libplctag.NativeImport has been released that includes these binaries.
@IanRobo75<https://github.com/IanRobo75> - in some testing I've found that if you set the target platform to x86 then NativeImport will not be able to interop with the x64 binary despite running on an x64 machine. This could be related to your BadImageFormatException.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#58 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AIY6RY6JM3XZKESXJJTTNT3R5NXYXANCNFSM4PB255VQ>.
|
|
Thanks for testing! |
|
Will the NativeImport wrapper get the string code soon-ish? And I assume the final C# wrapper would run the tag_get_string_length, then plc_tag_get_string_char for those number of characters and return the complete c# string to the user? |
|
Hi @IanRobo75, the string API is still being discussed. I have not started implementing it yet in the core library. |
|
OK. The offending line... Note: here I'm actually creating and adding the tag to a list, but that's been working fine up to now. So the important tag part, putting the parsed parts in square brackets for display here, is... |
|
Hi Ian - that seems to be a .NET exception - is that right? Does it repeatedly throw the error on adding the same tag (i.e. on consecutive runs)? I haven't come across this error before. It seems to be something related to the native binaries.. |
|
Hi @IanRobo75 - I've put together a string marshalling class and would appreciate if you could take a look at the implementation before it is released. You can see that there is different logic for each PLC type. There isn't an implementation for Plc5, Slc500, or Micro800 - but there is for ControlLogix, LogixPccc and MicroLogix. Any feedback you've got for this would be great. |
|
will test at some point, just really busy currently. |
|
OK, just getting back onto this. Frist issue, just reading through StringMarsahhler.cs before I start.... PLC5, SLC500, and MicroLogix all use strings of 82 characters. With the length bytes header assumedly they are all 84 bytes long, which makes sense because they all are LogixPCCC really. I'll modify accordingly for my tests with MicroLogix. |
|
Thanks @IanRobo75 ! |
|
So, I've cloned the github code, libplctag/libplctag.NET, (libplctag alpha 13 & libplctag.NativeImport 11 beta). Doing a new test referencing & using the LibPlcTag class in a forms app, just reading an integer, N7:2, from a MicroLogix... using System; ..... I get the error 'libplctag.LibPlcTagException: 'ErrorNotFound' However, my NativeImport 11 beta test app read data fine from the same PLC.... using libplctag.NativeImport; .... |
|
Hi @IanRobo75 - seems like the tag creation isn't working. What is in master at the moment doesn't have a version number. If you cloned this commit then you'll also need to make a call to Initialize(). What is the attribute string generated by the library? You can set a breakpoint here to find out. You don't need to provide a blank string if the path is intended to be unset, leaving it as null is OK. |
|
Yes, Initialise sorted it. |
|
OK, testing reading strings... Relevant parts of my code: //----------------------------------------------------------------------------- Works great once I changed the following in StringMarsheller.cs, particularly MicroLogixDecode: //---------------------------------------------------------------------------- //----------------------------------------------------------------------------- The fixes in MicroLogixDecode are required otherwise you get errors writing 1 byte past the length of asciiEncodedString. Also I've stepped in 2 bytes and dealt with the odd number strings. I believe MicroLogixDecode should also work for PLC5 & SLC (also PCCC). I assume they are byte-swapped as well. The size of a Micro800 string (atomic type SHORT_STRING) I got from reading a Kepware Micro800 driver manual. 256 chars did seem excessive and unlikely. |
|
I will set up the C API to use 82 characters for Micro800, but I thought I saw them return a single byte for the count word. I have not had access to a Micro800 for a long time. |
|
Do, you are right. Just opened up a CCW project for a Micro800 and strings are 255 characters, so assumedly the first byte is the length as you thought. Micro800's are terrible anyway, should be avoided. |
|
Thanks for checking. I have not had the "pleasure" of using one in a project. I remember that at least one PLC type returned strings without any padding. Might have been Micro800? |
|
SLC500 String: |
here is my updated StringPlcmapper.cs file, tested reading & writing strings to/from both a MicroLogix & an SLC500:using System; namespace libplctag.DataTypes } |
|
Very nice! Do you want to open a PR for this or do you want me to just copy it from here? Your timing is good, we are very close to releasing a public beta on nuget that's closer to a first 'stable' release. |
|
you copy it in.
Cheers,
Ian
Ian Robinson Machine Safety & Automation Engineer
[swarmIQ_colour 20%]
From: jkoplo <notifications@github.com>
Sent: Wednesday, September 2, 2020 3:59 PM
To: libplctag/libplctag.NET <libplctag.NET@noreply.github.com>
Cc: IanRobo75 <ian@acompleteloss.com>; Mention <mention@noreply.github.com>
Subject: Re: [libplctag/libplctag.NET] SLC Strings - PLCTAG_ERR_TOO_SMALL (#58)
Very nice! Do you want to open a PR for this or do you want me to just copy it from here?
Your timing is good, we are very close to releasing a public beta on nuget that's closer to a first 'stable' release.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#58 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AIY6RYZM4RBJXREDUGSALGDSDW7JRANCNFSM4PB255VQ>.
|
Is reading strings from a MicroLogix (SLC plc type) supported?
I'm reading from and writing to other data types fine, but when reading a string, e.g. ST102:0, I get the error PLCTAG_ERR_TOO_SMALL. Element size is 88, so seems right, confused why the error.
The text was updated successfully, but these errors were encountered: