MrPLC Member
  • Content count

  • Joined

  • Last visited

Community Reputation

6 Neutral

About lamboom

  • Rank

Profile Information

  • Country United States
  1. Image primitive for Red Lion Crimson 2.0

     Hi Joe E. & Jazzplayermark ...  Sorry I've been away.  Somehow got locked out of the account, forgot my password. and didn't know there was a junk mail for  on my PC  DUH! I have finally met with success, with some really good suggestions from Kolyur  on my thread, I also posted there.  I wasn't sure which forum would be best for Red Lion G3: My favorite solution is to create a file in the root directory of C:\  named Pics. in that file is the program makepic (copied it from the Red Lion Controls install files also in the root directory)  along with all the .bmp photo files I wanted to convert and load into the Red Lion Compact Flash to save memory.  However, the photos do not have a .bmp in their name. (like Photo1)   Then open the command prompt as administrator, and change directory:  cd C:\ Pics     Now, the command line is very simple:   C:\ makepic  Photo1.bmp 1      Notice the spaces ... no quotes!  no backslash.  That "1" at the end can be any number between 0 and 999 .. which is used by the HMI to call the picture from the Compact Flash. If you use any of the "switches" like  -wide  (use RGB 555 16-bit color values), the command line would look like: C:\ makepic  -wide Photo1.bmp 1 One thing that caught me, is the picture won't show up on the PC when programming the Red Lion, but, it will show up on the HMI... I did contact Red Lion Support... and got a better tutorial than was posted in their C2 manual ... But, I liked Kolyur's method better... Thanks for your help .. there are many ways to screw up this process in command line programming.  especially if you are not fluent in that area.   
  2. Image primitive for Red Lion Crimson 2.0

    Thanks, Joe     I think picture1.bmp 1 is correct.  And, you have the command line correct also.   I posted this problem in  got some interesting solutions .. This isn't so easy after all.. Then I'm reminded that there is a simple way to load a picture file in Crimson 2.0 (which I wasn't aware of's not mentioned in the manual     Only thing in the manual is the stuff i posted above. There's a good solution at the end of that thread .. like putting all the important files, makepic & the actual .bmp picture in a folder in the C:\ root directory or on the desktop..and run a simple command line for that configuration.      Will try that next.  .... because placing the image files in the compact flash saves a lot of HMI's memory.    Thanks again for your reply ... I'll get back to you if I have any success...          
  3. Image primitive for Red Lion Crimson 2.0

    Perhaps this is best a post for Windows 7 help Forums.. This is more an issue about the proper operation of Command Prompt, than anything related to the RedLion HMI... sorry, But that's the way RedLion chose to do this.  I can navigate to the final folder where "makepic.exe" is located in the command line... but how to launch the beyond me, and the above text from RedLion.   I was just hoping that if this above instruction makes any sense to you out there, you might give me some clue what the steps and expectations are.  I have a folder: MyImages, which contains two images: picture.bmp 1 and picture.bmp 2    That folder is located at C:\  MyImages.   The folder where makepic.exe is located:   C:\ Program Files (x86) \ Red Lion Controls \ Crimson 2.0 \ makepic The instruction above claims  makepic C:\MyImages\picture.bmp 1  ... as a command line, will launch that application, and make a file "under the makepic installation folder"  (whatever that means?)   Yes..I should ask Red Lion support directly.... sigh!     but, this isn't really a RedLion problem (other than their bad instructions) it's a PC thing isn't it... ?    Thanks
  4. Page 171 of the Crimson 2.0 manual for RedLion G3 HMI series talks about being able to display a photo/image as a primitive object.  On the HMI G3 series that must use Crimson 2.0.   The photo must be stored on the installed Compact Flash, using a command line utility program called "makepic".   The manual mentions most of the steps required; but, like so many "instructions", the Devil is in the details. I need a little help to launch this user program .. kind of a "tutorial"   Because I'm not really good with Command Line processes.    Yes. Crimson 2.0 is dated stuff, and Crimson 3.0 is awesome.. and it's very easy to use pictures on your HMI with C3  (been there done that I'm new to C2 ..  an' didn't appreciate what can happen if you purchase a RedLion G3 on eBay, without checking first if it can be configured with C3 ..DUH.   I just need the starting steps to launch makepic"  Thanks much, Regards, Michael
  5. Thanks to many people on this forum, and automation engineers in in several countries, not evolved with this forum, I have been able to almost finish a long project which uses the NJ and an NA HMI to manage LinMot linear motors.  However, Omron doesn't seem interested in working with LinMot .. Omron already has their own linear motors.  LinMot isn't real interested in the Omron systems controlling their drives and motors, they have a relationship with Rockwell.   In spite of this, the two systems do work well with each other, both Ethernet/IP and EtherCAT LinMot Drives will interface with the NJ, even while also using Omron Drives and motors at the same time.      There is no one in the Omron court that I know, which builds machines using LinMot ... soooo, I'm asking the forum for any contact information of someone you know, that does.  Thanks much,   Regards, Michael Lambert PS: this is a bit dated .. but it shows one early application:
  6. Here's some Axis Settings .. in case anyone out there has worked with LinMot: Have been getting too many following errors .. so the limits are high.
  7. It seems to be working fine ... sort-of   However It isn't stopping the actuator when there's a following error.. and the servo is being turned off too when there's a fault.  That might be the problem.. Ya gotta have the servo on in order to stop the slider.  Then turn it off "only" if the slider is stopped.  It should take only a millisecond to stop the thing.   As of this time.. problem is not resolved.   There might be good support at LinMot now that there is an Omron Automation engineer there.  He gave me the same solution IO did about a day after IO posted his reply. I didn't expect a solution from LinMot, and was quite surprised .. I believed this was a Omron NJ problem... or, a problem with my program, and the communication between the LinMot drive and the NJ.    So far, following errors are tending to slam the slider into the hard stop, as a solution to an error.   That doesn't happen with the Delta Motion,  motion controller... it just stops the slider instantly, when there's an important error. Will get back to you & IO when I figure out what's going on... thanks. One more thing.. sometimes the  MC_ImmediateFault is activated and the LinMot Drive is left ON!  So much for stopping the Drive. I'm thinking this Function Block has no effect on the LinMot drive..the only thing that is stopping the drive is when there is the eventual error caused by a programming error in the  NJ, and the result being the slider slamming into the hard stop.. now you have a "drive error"... and the drive shuts off.
  8. Hay  Crossbow .. always nice to get your take on things.    I started this thread because I wasn't getting proper stops when errors occurred .. what I got was an attempt to fire the LinMot slider into the next county!     I'm going to try this with the MC_Stop errors included .. what could go wrong..  
  9. IO  ...Thanks again    I had to search to figure out why I didn't find it the first time.  So much of the Omron manuals provide information in a minimal, intuitive nature.  I understand .. when you have a 1700 page manual, fewer words can be beneficial if you are going to print the thing; however, today it really doesn't matter how large the manual is.  17,000 pages if fine, a computer doesn't care .. and you have a "search" routine to find anything fast. The "problem" is me .. I'm not an automation engineer, but I play one in my lab ... and with the help of good, understanding people on this forum, and others, I will soon complete a project that took several years to optimize. so, the solution is simply this?: Perhaps I'll add those "Stp_Err" and "Stp_Ca" .. thanks to your latest explanation, can't hurt.    My machine will be run by humans, nothing automatic about it .. what could go wrong!
  10. This looks like the only Omron source of info on this subject: Pages 10-19 to 10-22 of Omron manual W507 CPU Unit ..Chapter 10, Sample programming: Stopping an axis during single axis operation: You can see the 'FaultHandler" Program at the top .. activated by MC_Axis000.MFaultLvl.Active  (which is TRUE when there's a minor fault level for axis 0) As IO_Rack says .. It's a user program .. you just do whatever you want when there's a fault ..  But, it's not what is at the bottom of this example program .. which is more what IO_Rack is talking about, only the use of MC_Stop and MC_ImmediateStop is still involved at this program's end .. and is separate from the "FaultHandler" line.   (which is "Device" related) Because I already use MC_Stop in my programs,  I find this example very confusing because MC_ImmediateStop is shown linked to MC_Stop's "Stp_Err" and "Stp_Ca" OK..unless someone says otherwise, I will just connect MC_Axis000.MFaultLvl.Active  to the Execute input of IMD_STP .. that will be my "FaultHandler" I just got a similar suggestion from LinMot support, with the additional consideration of Axis settings: "Other Operation" and "Limit Settings" need some attention.     Thanks all... Regards, Michael
  11. Thanks for the reply IO Duh!  I get it!    I'm just too used to the machine providing all the programming, and i just select the little blocks and paste them into ladder diagrams ... (actually, I have quite a bit os ST in my wave tank programs.   Now that you mention it ... it should have been obvious.  There must be a "Best Practices in programming" somewhere in their thousands of pages, and hundreds of manuals ... I think they did a good job for the beginnings of programs, but not so good for ending them.    For the moment, I'll assume I just missed it.  Thanks again for the wise solution..     Regards, Michael
  12. I’m using a Omron NJ to manage a LinMot linear motor .. all is going very well; however, there have been a few times during this development phase when the actuator, or programming creates a fault, perhaps from a following error, or exceeding a limit.  The result is sometimes scary.  The actuator might accelerate into a hard stop.  Not a big deal, the ends are protected with Sorbothane, so it isn’t a big problem .. yet.  Once the system is correctly programmed, it shouldn’t ever accelerate an actuator into the hard stops. In spite of my newbie-ness  to Omron programming I’m aware of the need to employ error & fault action that will stop a run-away actuator in closed-loop control, rather quickly. Just how to do that.. has evaded my research. I’ve noticed:  “FaultHandler”  in the W507 & W508 Manuals. And, been quite frustrated to not find any reference to FaultHandler or FaultHandeler()  .. which kinda suggests it’s a program?… and also expected to get some clues in the "NJ Programming Best Practices V1.1”   so far… no luck. Perhaps I’m going about this all wrong..  The LinMot Driver Controller might be the way to go.. An error message from the NJ to the LinMot drive would quickly shut down movement in closed loop .. instead of turning the motor into a rail gun… Any suggestions at how to do it with the NJ,  would be greatly appreciated.. Thanks Regards, Michael PS: here’s the progress so far, thanks to many out there, and on this forum ...  
  13. Red Lion C programing - Wait? RESOLVED

    Thanks Nj Controls .. I posted this on Forum too.. just in case no one took me seriously here.. It's kinda a basic question.. Turns out one shouldn't use C programming for a position control program from an HMI.. there are unintended consequences in the HMI for loops which are paused to await a condition before continuing.   This program is easily done in the Motion Controller, which has "wait for" conditions available in it's "user programs" (the ones you write)  The Red Lion uses programs that can be called from the HMI's pages. Those programs must be written in basic C.    Using loops that wait for position conditions which are initiated by the HMI, by sending parameters and a start command to a Driver/Controller .. is not recommended.     However, some of the suggestions I got on were to use  while ( !inPos ){// do nothing} for a wait .. but that could end badly.. but would work if all went well. Or: switch Step { case 0: if start then issue Home(); Step:=1; Break; case 1: if Homed then issue MoveAbsoluteToZero(); Step:=2; Break; case 2: if Inpos then issue Sinewave(); Step:=3; Break; case 3: if Abort then issue Stop; Step:=4; Break; case 4: if Stopped then Step:=0; Break; } Not exactly..but something similar should work.
  14. Anyone ever used a Wait-for digital tag in a C Program? I have to use C in the Red Lion Programs.. but, I'm not at all proficient in C (or anything else for that matter ..) Here’s a nice problem for basic C programming .. I really need to solve it .. but, so far ... can't ... sigh!: I have an actuator that will be commanded to make sine wave motion.  The program that does that, in the actuator’s driver-controller, requires the actuator to first be in a zero position.  Homing has already been done, so the drive knows where the actuator is.  I cannot modify the sine wave program; but, can command a Move Absolute program in the drive, to take the actuator to zero, if it isn’t already there.  When the actuator is at zero, it is “In position” and a digital tag will go True. If the Tag is False, the actuator is not at zero, it’s at some other position,  and only the Move Absolute program can return the actuator to zero. So, when launching this position command program, In a Red Lion G3 HMI, using only Basic C programming, how would you write a control program that would test the status of the actuator’s position, and, finding it at zero (the “InPos” tag is true) would start the Sine Wave program.  And, If the “InPos” Tag is false, would start the Move Absolute program, which would return the actuator to zero, and when the actuator is In Position, would start the Sine Wave program. Here’s the tricky part. It will take only a few milliseconds to start the Move Absolute program (if required) .. but how do you get the “C” control program you are writing, to wait until the actuator actually reaches zero, and the “inPos” tag goes true … which could take several seconds? I don’t believe there is a WaitFor function in “C” , and you cannot send either the Move Absolute, or the Sine Wave program more than once .. so, if a loop is used, it can loop only one time .. presumably with conditional delays. (however that's done)  You cannot use Sleep().. that would be cheating.. the full program must run in the least amount of time, and you do not know how far the actuator is from zero. You could use if (! InPos) or if (InPos) to qualify what programs to run .. but, where does the “Wait for In position”  fit into C Programming?  You might be able to use Continue .. but, ya still have to wait for “InPos” to go True…..before running the Sine Wave.       Thanks Much, Regards, Michael
  15. NJ controller firmware upgrade.

    Perhaps I can help ..  I said earlier .."And, I'm going to Omron to get away from Siemens."   This implied no comparison between Omron NJ and Siemens S7-1200 .. they are quite different after all...  However, where they are NOT different, Is the complex and expensive manor that firmware upgrades are performed ...  I think Crossbow thought I was comparing the CPU's