Jump to content
OMRON Forums


  • Posts

  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Marina_IFRC_at_URI's Achievements


Rookie (2/14)

  • First Post
  • Collaborator Rare
  • Conversation Starter
  • Week One Done
  • One Month Later

Recent Badges



  1. We also had a very bizarre problem back in May where time was being calculated more slowly than it should have been, we had to do a hard reset and change a fair number of settings to deal with that -- the tech support people we called at the time called it a " very interesting" problem and spent a great deal of time looking over it -- and the supervising professor (he had worked on an older model at MIT) tried to fix it by altering jumper settings when it turned out that was no longer necessary in more modern UMAC/PMAC systems so I do want to check those to see if some of the communications jumpers were possibly altered by mistake.
  2. We had one of our grad students drop a 15 V DC wire in the UMAC across a 230 V / 20 amp AC live power line while dismounting a robocontroller and the USB stopped working on the PMAC in addition to the power supply (I was frankly amazed it wasn't more badly damaged). This was sent in for expedited repair back in May and returned officially fully repaired, we had asked them to check everything in both the power supply and the PMAC itself, so I assumed they should have fixed it if there was a problem present. Interestingly, though, when you try to plug the IDC10/DB9 connector I wired together for it into the auxiliary rather than main port, the UMAC faults and most of the lights turn off -- it goes back to normal the moment it is unplugged. Maybe the repair isn't complete, but the lab's supervising professor is not interested in wasting any more of summer after that unpleasantness, so we're going ahead with ordering the "Pcomm Server Pro 2 Library" so that I can implement what I need to in ActiveX.
  3. Those are the settings we have used for every attempt unless Steve specified otherwise, but they were the settings I established at the beginning of working on this. Yes, we used it to configure the motion controllers to begin with. Yes, it does. Is there a particular urgency to this? UMAC power has been cycled many times since the setting was put at I54 = 12 . This is the one thing that I cannot confirm at this time. I will check it today and report back here if they are incorrect.
  4. Alright, I have a correctly configured cable (crimp pin DB9, my soldering is terrible) and do not get a connection to the Delta Tau both with hardware handshaking on and off. Any ideas from here ? The person who originally did something like this used the J7 on the Turbo PMAC but apparently the old version had the J7 as a 26-pin, we just have two, main and aux, IDC10 connections. I was wondering if the reference in the UMAC Turbo HRM to Serial-Port Level Select Jumpers for RS-232 or RS-422 is relevant despite the switch in the serial port design for our board and if I should check those jumpers as a next step? Alternatively, this whole project started back in June when we tried to order the "Pcomm Server Pro 2 Library" (what we're doing is extremely similar to what a fellow named meindert.norg previously implemented on this board, though we need more expansive functionality after that point) to allow us to just not worry with serial communications and use ActiveX, but your salespeople never called us back so we tried to implement it with parts on hand (long summer vacations, apparently). Thank you kindly.
  5. Thank you very much. I'll begin implementing it immediately and post again here if any more communication problems ensue.
  6. A straight up 1 - 9 to 1 - 9 equivalency connection. I was using a Vaster cable 700-009-C female-female stock as ordered for RS232.
  7. I1 = 0 ; I54 = 12 ; I am set for 38400 baud as I understand it based on the I54 value. I wasn't sure of the relationship between the CS handshaking setting and the hardware, so I went with the default as I understood it. EDIT: I just cycled through the values for I1 without effect, saving them and then reverting each time, though I didn't power cycle PMAC or the Delta Tau and left the USB cable in which is maybe not best practice.
  8. Yes, the UMAC has a USB port and we've regularly communicated with it without difficulty including the full range of downloading and executing motion programmes to it. Of course, we need the serial communications to function for our long-term efforts, so my first step was to establish equivalent communication functionality via serial port.
  9. Thank you, Steve. I corrected that setting to "hardware" and I now consistently get a "unable to communicate" message instead of the prior update firmware message, with no luck after reset of the PMAC and the host computer. The connection we're presently using for the serial cable (as a bit of added detail) is from the IDC-10 male port on the PMAC with a female/female IDC-10 to DB-9 cable connecting to a regular female - male DB-9 cable into the host computer (which due to space geometry issues is located about eight feet from the PMAC). The supervising professor of the lab suggested soldering the IDC-10 male connector directly to the serial cable but I'm not precisely sure that would help at all establish a connection.
  10. Greetings. I am responsible for configuring a Turbo PMAC2 pro installation (via UMAC) for automation of research processes using motors. Ultimately the intention is that based on prior analysis matlab will automatically generate new PMAC programs and send them to the Turbo PMAC. Presently we are attempting this via a serial communication with the main serial port. This question does not pertain to the direct serial interface between the PMAC and matlab as we haven't gotten to that point yet. Rather, the problem exists in a properly configured for 38400 baud serial connection simply trying to establish a communications link to the Turbo PMAC via Pewin32Pro2 (version 4.2). Data bits: 8 Parity: None Stop bits: 1 Flow control: None and the settings in Pewin being: Parity: None CTS Output: enabled RTS Control: Enabled Timeouts (msecs) : Character 2000 Flush: 30 And baud rate correctly set at 38400 on both the computer and Pewin with the Pewin going to COM1; which is how the computer (running Windows 7 64 bit) is also set, so these are all checked. I have attempted in both regular mode and Windows XP SP.3 backwards compatibility mode for running Pewin to simply establish a communications link. The serial cable is in the main, not auxiliary, serial port--though I've tried the auxiliary port and it just froze Pewin, which wasn't cleared until I rebooted the computer. At any rate, I either get a message saying that I63 and I64 cannot be set to 1 and to "please update the firmware" while claiming communication is established (but no commands can be sent), or I am unable to establish communication at all. Which of these I get appears fairly random. Any recommendations on how to proceed from here to clear this problem and enable regular Pewin/Turbo PMAC serial communications so that we can check those and move on to the next step in our project? None of the later is the concern right now, just regular downloading of programs through Pewin as a test. Thank you kindly in advance.
  • Create New...