Red Lion DSP Serial Help

[hellohelp]

Hello,

I am attempting to set up a database using a DSPSX000. I am connecting to a device that outputs a results file via RS232 at the end of a test. I would like to gather these results and save them on the DSP in a csv format.

Currently, I have a Raw Serial driver set up with the device acting as a master as it automatically sends the results after a test completion. From there I have used the PortInput function to attempt to gather the results, and set these results as a character data tag.

I am a little lost when it comes to the Data Logging feature of the DSP. I have set up a flag tag to go high when the program is run so that a triggered snapshot can be taken. Does the DSP require a compact flash card to be able to store a csv?

Sorry if this is all a little vague, this is my first adventure into Crimson and Red Lion products, and I am feeling a bit overwhelmed with it.

Thanks for any help.

 

[kolyur]

Does the DSP require a compact flash card to be able to store a csv?

Yes, you will need a flash card installed in the unit to save CSV files.

I expect that setting up the data logging will be the easy part of this job as it is all fairly automated in Crimson. Doing the RS232 raw serial will be more of a challenge since it requires a bit of programming to receive and parse the data.

Post any specific questions you have and we'll try to help.

 

[OkiePC]

https://www.youtube.com/watch?v=1EmZgp-2E3U

Since you already have a character tag and a trigger tag, you can skip the first 3-4 minutes.There are nice editor tips at about the 3:00 minute mark, then it goes into how to set up the datalog.

Their example is continuous (timed intervals) logging, but yours will be triggered, so from there, you may run into questions...

I found some of the Crimson field labels confusing at first and had to tinker with it a bit to get the desired results, but being so easy to update, by trial and error, it didn't take long to get the log file appearance I wanted.

 

[hellohelp]

https://www.youtube.com/watch?v=1EmZgp-2E3U

Since you already have a character tag and a trigger tag, you can skip the first 3-4 minutes.There are nice editor tips at about the 3:00 minute mark, then it goes into how to set up the datalog.

Thanks for the video and the information. That was helpful to see what all of the fields do.

Yes, you will need a flash card installed in the unit to save CSV files.

I expect that setting up the data logging will be the easy part of this job as it is all fairly automated in Crimson. Doing the RS232 raw serial will be more of a challenge since it requires a bit of programming to receive and parse the data.

Post any specific questions you have and we'll try to help.

I have a compact flash on its way tomorrow. In the mean time, is there a way in crimson to be able to test the database? I would like to test the communications along with getting the long character string before I break down each result field into separate tags. I am currently using:

cstring results = PortInput(2, 0, 0, 3000, 256);

I was hoping that I could use this for communication testing today to be able to grab the entire results string before I start to break it down into individual result field tags. I have the program run on the RS232 update. Would there be a way to ensure the communication and results character string come through by connecting my PC to the DSP?

Sorry if these are all amateur questions, I have attempted looking through Red Lion resources, although I find them a bit vague. I appreciate all the help so far.

 

[OkiePC]

I used Sandisk Ultra up to 32g if I remember right with no problems.

No logging or remote downloading without a CF card. I think you can configure the log and download it, but I do not recommend that. Go ahead and set it up how you think you'll want it, but don't enable it until you get the card. But, you can work on your tag dissection logic. You could make an array of cstring tags and practice FIFOing data into that array to test your data collection and communications logic.

Almost forgot: Unlike some other brands, it is important you do not insert or remove the card with power applied to your Red Lion.

 

[kolyur]

Even though the DSP doesn't have a display, it can be used as a "virtual" HMI. You can set up display pages in Crimson that can be viewed through Internet Explorer over an Ethernet connection. This is convenient if you're already using Ethernet to program the unit.

The general steps would be:
1. Assign an IP to the DSP if you haven't already (needs to be in the same subnet as your PC).
2. Turn on the web server enable in Crimson, then turn on Remote Viewing and if necessary Remote Control.
3. Configure your display page(s) with whatever tag primitives you need.
4. Put the IP address into IE (http://xxx.xxx.xxx.xxx)

 

[hellohelp]

I used Sandisk Ultra up to 32g if I remember right with no problems.

No logging or remote downloading without a CF card. I think you can configure the log and download it, but I do not recommend that. Go ahead and set it up how you think you'll want it, but don't enable it until you get the card. But, you can work on your tag dissection logic. You could make an array of cstring tags and practice FIFOing data into that array to test your data collection and communications logic.

Almost forgot: Unlike some other brands, it is important you do not insert or remove the card with power applied to your Red Lion.

Great info, especially with hot swapping the card. I may try to just set up PuTTy real quick to send the same header info with some character strings.

Even though the DSP doesn't have a display, it can be used as a "virtual" HMI. You can set up display pages in Crimson that can be viewed through Internet Explorer over an Ethernet connection. This is convenient if you're already using Ethernet to program the unit.

The general steps would be:
1. Assign an IP to the DSP if you haven't already (needs to be in the same subnet as your PC).
2. Turn on the web server enable in Crimson, then turn on Remote Viewing and if necessary Remote Control.
3. Configure your display page(s) with whatever tag primitives you need.
4. Put the IP address into IE (http://xxx.xxx.xxx.xxx)

The web server seems interesting. Are the display tags drag and dropped onto the virtual hmi and auto updated? Or is there some update programming that needs to be done in the background?

 

[kolyur]

If you have trouble with the PortInput command, try using PortRead, if only to verify your communications. PortInput can be troublesome if you don't get the arguments just right because it will return nothing even if some data was received.

Another problem I encountered was that since the G3 is always monitoring the serial port, you can end up with garbage data in the buffer. Tech support advised me to use this command:

while(PortRead(2, 0) > -1) {}

which clears the buffer prior to reading your actual data. (This tip may apply more to a Master setup where you are sending a command and waiting for a response.)

 

[kolyur]

Are the display tags drag and dropped onto the virtual hmi and auto updated?

It's almost that simple. Drag a primitive--Crimson's name for a display object--onto the display page, such as a Data Box (under Core Primitives). Double click on it and assign a tag in the Data Source field. When you have the page shown in Internet Explorer, the display will auto update about once per second.

Note: Only IE will work. Forget using Firefox, Chrome, etc.

 

[OkiePC]

I used Chrome with my G3s to overcome performance issues with IE. That was over a year ago. When you "remote in" to the device, you will be looking at the display pages you create as if you were programming a G3 HMI with a touch screen. So you can do anything an HMI can do.

You can add buttons to perform logic, display lists of tags, anything you can imagine, and when you are connected, the mouse will perform the "touch" operation almost exactly like you were standing in front of a real touch screen. Look back at that youtube link and search for some others from Red Lion on building simple pages. The video tutorials are very basic but there are nice tips in them and they are enough to get you started with the editor.

 

[hellohelp]

Thanks for all the help!

I've got the compact flash card installed into the DSP, and have been attempting to get the data logging feature to run to no avail. Maybe someone can help me spot where I'm going wrong?

I have the raw serial set up with the correct parameters. The device I am attempting to get data from will automatically send the results via serial after a test completion. To start, I just would like to ensure that I am communicating with the device. So I have created an internal string tag set to 256 characters, and in the Update field on the raw serial port, I have Program1()

Program1 is simply:
//raw serial string
cstring _SerialString;

//Flag tag for data logger set to false
LogTrigger = false;

//Grab the results info
_SerialString = PortInput(2, 0, 0, 3000, 256);

//If the string is not empty, save the serial string to a results string tag
//Set the data logger trigger to true
if(_SerialString != "")
{
Results = _SerialString;
LogTrigger = true;
}

Which I would hope would initiate when the Master device sends its result information and the function would grab up to 256 characters and end when no characters are received after 3 seconds. The LogTrigger would be set to true to take a snapshot of the Results string tag. I have the Results tag set as the contents of the data logger.

Attempting to run the 'Watcher' live, I never see the LogTrigger go true, which leads me to believe I am not communicating with the device. Is there anything I'm missing here? Do I need to set up the DSP to be a slave device somewhere? I would think that I should just be able to log a string that gets initiated from a master device pretty simply.

Thanks again for all the help and direction. I think I am picking up Crimson decently quick.

 

[kolyur]

First of all, are you absolutely certain that your serial cable is wired correctly? Homemade cable or purchased? I assume you've double-checked baud rates and such.

I'd suggest changing your program to use PortRead instead of PortInput. Even if it only reads a single character, you'll know whether you are receiving data or not. (The alternative would be to put an oscilloscope on the Rx wire.)

 

[hellohelp]

I'm definitely wired correctly. I used the PortRead function and used the live watch window to monitor, and I'm receiving communications.

For PortInput, do I need the exact length of the serial string? I hope not as the results string can vary in length depending on results.

 

[kolyur]

For PortInput, do I need the exact length of the serial string?

I believe the problem I had with PortInput was that if you don't receive the exact number of characters you specify, the command returns nothing (even if partial data is received). This really threw me for a loop because the manual suggests that whatever data has been received will be returned when the timeout expires. My memory is a little fuzzy but that may be your problem.

I'd suggest using PortRead. Even though it only reads one character at a time, you can easily set up a loop in your program to put the whole buffer into a string. Like this maybe:

cstring str := "";
int char;

do{
  char := PortRead(2, 2000);
  str += char;
}  while (char > -1);

PortRead returns an ASCII character code so it must be stored in an integer variable. The += assignment basically appends the single character onto the end of str.

 

[hellohelp]

I'll go ahead and give that a go. Thanks for the information.

Does crimson have any functions to parse a string? I have the reference manual but have not seen anything. If not, I can just use another program to parse when I get the files.

Thanks again!