BE

Likewise. I know this question is old, but found something today that might be of use to others later on. I was trying to get a data display to show text and timespan using the custom formatting option, but it was only displaying the timespan data (ie. no text). I will caveat this by saying I haven't tested this on an HMI yet, but it does work in the simulator. Omron doesn't document this anywhere I could find, so it was simply trial and error. VBA has custom formatting options for timespan variables (see here: https://learn.microsoft.com/en-us/dotnet/standard/base-types/custom-timespan-format-strings ), and as it turns out, these can be applied to data display objects using the numeric custom value format. For example: Set the DataType of the Data Display to "Numeric" Value Format = Custom CustomDisplayFormat: My Time Label: {0:hh\:mm\:ss\.ff} Details on what the characters and formatting do are documented in the above Microsoft link. The above results in a data display that displays "My Time Label: 12:15:30.25" (minus the double quotes). So not only can we include text in the data displays for Timespan variables, we can also control the resolution displayed simply by using the HMI formatting.

So thought I would share my Danfoss Function blocks now that I have a site running properly. Don't mind the St prefix on all the names, that is just a method I use to assist in being able to tell at a glance where a function or function block is used in my programming. My last project has over 50 custom functions and function blocks, so the list can get rather long. Description of the function/function blocks below: StDanfossDs402StatusWord: This function just breaks down the status word into named booleans. StDanfossDs402CtrlWordStartup: This function block is part of StDanfossDS402CtrlWord, and does the initial sequence with the control word to get the drive to a ready state StDanfossDS402CtrlWord: Controls the control word after the startup function block has completed There are also 3 custom function blocks for reading/writing data via SDO's (2 different writing FB's, one for DINT data, and one for STRING data). I created these to make my life a bit easier, mainly as it relates to the SDO address vs the Danfoss parameter number. Most stuff is (ie. should be...........) commented, so it should be pretty straight forward for someone to work out what is going on. With the writing, you need to specify the data size and I found the easiest way to work this out was read the relevant parameter first, as this gives you the read size of the data, which is the same as the write size. Danfoss FC302 Function Blocks.smc2

Are you looking for the "Edit PDO Map Settings" by chance? Its the button 4 rows up and to the right of "Setting Pararmeters", and allows you to enable and map PDO options specific to the device.

If you select "Display All Objects" when you add a PDO entry, you should see something like the following: I will caveat this by saying I haven't done this yet, but did look into it this week because I thought I was going to need it (didn't end up needing it). I believe those entries relate to the mappable PDO objects in the VSD. These can be assigned through the MCT10 software from Danfoss. It is worth noting that the entries are 16bit, so 32 bit parameters need to use 2 consecutive entries, which is detailed in the MODBUS RTU operating instructions (of all places lol).

So this got me out of trouble last week......so figured I would post for anyone in the future. I decided to use the 402 profile for a couple of projects I am working on, well, just because I can 🙂. Using the FC profile (that I have used previously), you can just set the control word to the value you need as soon as the VSD turns on (as I described previously) and the VSD is then happy to operate. Turns out that under the 402 profile, this is definitely not the case. So my previous comment about what bits to set and reset under the 402 profile doesn't work in the context I described it. The final word value in @VulpesLago start-up process is 7. But if you apply this value to the drive as soon as it starts, the relevant status word bits won't be correct, and the VSD won't accept any run commands. But if you follow the start-up process, you end up with the right status word bits on, and then the VSD operates correctly, even though the final value of the control word is the same. Effectively, the VSD seems to need to see certain control word bits on, with others off, in order for it to be ready to operate. Once I finish commissioning this project, I will upload my function blocks for future reference in case anyone comes across something similar.

Have you checked the column width settings? I haven't had the alarm viewer on a live HMI for a while (only a simulator), but any time I have had something similar I am fairly sure if the column widths are shorter than the text width, it just cuts the text off. But if they are longer (ie. all the column widths add up to more than the viewer width), then you get the scroll bar. I would have to test it to be sure.

Gee, learn something new every day.......think I am going to have to use that sometime 😁

The other thing they may say, is the system must be failsafe (or something similar to that). The only way to make the system failsafe is to use N/C contacts. If you use N/O contacts, and someone disconnects or cuts the E-Stop cable, then the E-Stop won't stop the equipment when it is pressed. An example text from one of our Australian Standards says "It shall not be possible for the emergency stop device to engage without generating the stop command.". Doesn't explicitly say that they must be N/C contacts on the device (ie. E-Stop button or similar), but N/C contacts are the best way of ensuring that the clause is met. That said, if you only need to contact for indication purposes on the PLC (ie. it isn't a safety controller controlling the safety aspects of the E-Stop), then a N/O contact should be fine. For example, I often use a 2 channel safety relay for managing E-Stops. The Safety Relay controls the disconnection devices but it also effectively has a N/O contact output for indication purposes. That contact is connected to the PLC, so the PLC knows if the E-Stop has been activated. (I say effectively, as the contact is technically N/C, but the coil is energised when the relay is on & E-Stops are all reset. So while the E-Stop is not active, the contact is open. The inverse is true for the contacts that control the disconnection devices) The safety relays I usually use reference EN 13849-1 & EN 62061 in their manuals so I imagine those standards have something to say about it. Australia has our own version of those, but I won't bore you with the relevant numbers, as they probably don't apply in Ireland 😁

I am assuming you are using an NA series HMI. To the best of my knowledge, you can't include a variable in the Message or Details fields of the NA series alarms. What you can do is go to the properties of the alarm, and it gives you a spot for "Additional Information". This can be a variable value (Boolean, Numeric or String), but shows as a separate column in the alarm viewer. What I have done in the past is just used a generic message in the Message column (ie. Motor Fault - Check this and that), and then used a string variable (max string length is 32) in additional information to indicate what the actual equipment was (ie. Conveyor 1). The column can be added, rearranged and renamed in the column settings of the alarm viewer object.

Providing they can get away with the DOL starting of the pumps (or maybe use soft starters), this is a good idea. Only downside would be if the VSD ever failed, there would be no redundancy with the other 2 pumps to regulate pressure (ie. they are either 0% or 100%). Putting 2 pumps on VSD's would alleviate that, but if that level of redundancy was required it would probably just be easier to run all 3 on VSD's 🙂.

Right, so now I feel silly. My file names were their total paths.....but the folders for those paths didn't exist 😐. Create the folders, and suddenly everything works perfectly. 🙂

Well I guess that means if using negative speed references, Bit 15 isn't exactly redundant then 🤣. That is a nice bit of information to store in the back of my brain though......might come in handy one day.🙂

Thanks, I just ran it with the controller you used and still had the problem. Guess at this point I get to wait for my Omron Support tech to have a look at it today. Cheers

Hi All, Most people who have played around with the SD card access in the simulator know that the data is usually stored at C:\OMRON\Data\SimulatorData\CARD which allows you to actually view the results of your code so you can make sure it is correct. Which can be very useful. The problem I have today is that the simulator will not write to it's virtual SD card. Selected device is an NX102-9000 CPU. I have some function blocks that I use for writing data to CSV files on the SD card (typically modified versions of PMCR's excellent function block below). But as soon as the function block executes to the first FileOpen function block, I get ErrorID 140E. I managed to find this code in manual W503 and it says “SD Memory card access failed”. Assumed causes being a broken memory card or slot. Neither of which should apply as far as I know, because I am in the simulator. Things I have tried so far: Triple check Sysmac Studio is running as an Administrator Ensure Sysmac Studio is up to date - Updated to 1.62 today, was previously on 1.61. Both version had the same result. Copy in a different version of the function block from a previous project (ie. because I KNOW it works, it has logged data to CSV files in a plant consistently for the last 2 years) - no luck here either, still throws the same error on the first FileOpen. Made sure the filename is within the 66 character limit (it is at 34, and that is the total path, not just the actual file name) Tried controller versions 1.61, 1.64, 1.68 just in case What I haven't tried: Testing with a physical CPU and Memory Card, mainly because the CPU is currently installed in the switchboard onsite, several hours away..... Testing on a different computer - unfortunately my laptop is in the throes of death, and my new one hasn't arrived yet. Any chance that someone would be able to do a test in Sysmac Studio to see if it works for you? If it doesn't work, then I guess there is probably a bug in Sysmac Studio. If it does work, then maybe there is something wrong at my end.

I will preface/caveat my comments with a couple of points: What you are trying to do is use Bypass Contactors on VSD driven motors. I have never seen this done, although a Google Search indicates that it is used in some applications. Consult with the VSD manufacturer before implementing anything, to ensure that your arrangement will not cause any issues with the VSD I have not consulted with my VSD reps to see if this is possible, and if it was something I wanted to implement, I would be consulting with them BEFORE implementing or designing anything. I personally can't see any reason to run something this way, unless there are concerns around the heat dissipation from the VSD's. It would be simpler to leave the pumps running at 50hz from the VSD. With the VSD's I typically use, they will 'ramp up' (or ramp down) even if there is no load connected. So the physical motor isolator could be off in the field, but the VSD will still "Ramp Up" to the setpoint. When the Isolator is switched on, the motor starts at that setpoint. This isn't something I typically do, but it is occasionally a necessity during commissioning and maintenance operations. Based on that, if your motor was running on the mains contactor (ie. Direct to mains power), I would think a switchover would simply require you to ramp up the corresponding VSD to 50hz, and then switch the mains contactor off, and switch the VSD contactor on. At this point, you can ramp the motor down to the speed required. Again, and I can't stress this enough, consult with the VSD manufacturer. Motor control is what they do for a living, and they are going to be able to give you the specific guidance and requirements for their VSD's that are required to implement what you want to do.