I am driving a Tic T249 stepper motor controller via a Ruby script on a Windows machine, and using the conventions outlined in https://www.pololu.com/docs/0J71/12.2. I’m having no issue interacting with the controller (either sending commands or retrieving status). My issue, however, comes from the fact that I am polling the controller at a relatively high rate for its status (about 10x a second), and this causes a command line window to launch and then close each time I make a call to ticcmd. The effect is that a command line window flashes on the screen 10 times a second, taking focus away from the gui that wraps my Ruby script. This is rendering the gui unusable to my end user, who needs to be able to interact with it.
I’m aware that this may just be a fact of life for how Open3/Ruby works, but I must not be the only one who needs to send commands to my T249 often without having a command line launching each time, because it impedes the usability of my program. Does anyone have an idea for a workaround on this problem? Note that I cannot use a language other than Ruby, and I’ve already attempted to wrap ticcmd in other Ruby functions for launching processes (backtick, spawn, %x) instead of open3.
When I run Ruby programs on Windows, I am usually running them from a Bash shell running in a MinTTY terminal. All of this is provided by the MSYS2 environment. The Ruby script and ticcmd both talk to the existing MinTTY terminal and do not open up any new windows. I have not tried incorporating this into a GUI. Could you tell me more about your setup? What language is the GUI written in and how does the user launch it? Does the GUI invoke a Ruby interpreter to run your Ruby program? What Ruby interpreter are you using?
Maybe if your GUI were run from a command line or compiled as a command line application, things would work better, because there would already be a console for ticcmd to use when it is launched.
Also, I am not sure if this will help, but I think you should try using Open3.capture3 instead of Open3.capture2. The key line in the example code that you linked to would need to change to:
We use Ball Aerospace’s COSMOS, which is essentially a “hub” that is designed to provide a unified interface & GUI for sending commands to and receiving/viewing data from lots of different kinds of hardware. One of those pieces of hardware we want to use is a stepper motor controlled by the T249. We launch it from Ruby on the command line (COSMOS is written in Ruby), and the command prompt stays open in the background. It then connects to my Ruby script via TCP and begins sending commands that my script parses, calling ticcmd as a result. We’re using YARV, which I believe is the standard Ruby interpreter at this point.
Sadly, using capture3 doesn’t fix the problem; I’ve already tried most alternatives to the sample code’s style of wrapping ticcmd that seem reasonable, including that. The only additional functionality it provided was capturing stderr, which I thought could stop the window from launching if it was opening only to display stderr output, which turned out not to be the case.
Where did you download your version of Ruby? How are you starting the Ruby script that runs ticcmd? You might try starting that Ruby script in a Command Prompt window so that when it runs ticcmd, ticcmd can just use the existing window instead of opening a new one.
The version of Ruby is 2.4.4. As I outlined, I can’t start my Ruby script through the command line, as it is simply an interface that’s then called by COSMOS (which is another program written in Ruby). The script is not meant to stand alone, it is used as part of a larger larger context, and as such, cannot be launched directly through the command line. Is the implication here that ticcmd simply cannot work without either being launched directly via a command line or opening its own command line?
The issue you are having is not unique to ticcmd. The default behavior of console applications in Windows is that they open a console window if they do not already have one available to them.
Can you try using the attached executable, ticcmdw.exe? This is a version of ticcmd that I compiled as a Windows GUI application, which means it will not work properly from a standard Windows Command Prompt, but it seems to work fine in other contexts, and does not open a console window when it starts.
By the way, you still have not explained where you got your version of Ruby or how your Ruby program is being started. The number 2.4.4 tells me about your Ruby interpreter source code, but not how it was compiled into a Windows executable. That is why I asked where you downloaded it. Ruby interpreters for Windows often come with two executables, ruby.exe and rubyw.exe, and there are multiple ways to start them running. Despite the missing information, I was able to reproduce a problem similar to yours by using rubyw.exe from MSYS2, and I suspect that ticcmdw.exe will work for you.
Thanks a bunch for your help, I really appreciate you putting time into trying to help solve this! That executable worked great for stopping the command window from popping up, but unfortunately completely broke sending commands to the driver. When I swap from the old executable to the new one, I can get the status of the controller and the status is up to date, but sending commands to the controller does nothing; I can’t get any motor movement, or change the limits. When I switch back to the old one, my commands go through just fine. Is there something I need to change about how I interact with ticcmd for the new executable to work correctly?
As for where I got my version of Ruby, it comes bundled with the open source COSMOS application that launches my script. We launch the overarching COSMOS application using the ruby executable from a batch file, not rubyw. COSMOS, which is written in Ruby, then directly makes calls to the script that I’ve written when it needs to interface with the controller.
I was unable to reproduce your issue here, so I suspect there is a problem with your system that is unrelated to ticcmdw.exe. Can you try switching back to using ticcmd.exe instead of ticcmdw.exe (without changing anything else) and see if you are able to control the motor? Are you able to control it from the Tic Control Center when your program is closed? Have you looked at the Status tab of the Tic Control Center and checked your Tic’s settings and connections?
